
Systems 

How to master the complexity 

Edited by 

Fabrice Kordon and Michel Lemoine 



FORMAL METHODS FOR EMBEDDED 
DISTRIBUTED SYSTEMS 




Formal Methods for 
Embedded Distributed 
Systems 

How to master the complexity 



Edited by 

Fabrice Kordon 

Universite P. & M. Curie, 
France 



and 

Michel Lemoine 

ONERA Centre de Toulouse, 
France 



KLUWER ACADEMIC PUBLISHERS 

NEW YORK, BOSTON, DORDRECHT, LONDON, MOSCOW 



eBook ISBN: 1-4020-7997-4 

Print ISBN: 1-4020-7996-6 



©2004 Springer Science + Business Media, Inc. 



Print ©2004 Kluwer Academic Publishers 
Dordrecht 

All rights reserved 



No part of this eBook may be reproduced or transmitted in any form or by any means, electronic, 
mechanical, recording, or otherwise, without written consent from the Publisher 



Created in the United States of America 



Visit Springer's eBookstore at: 

and the Springer Global Website Online at: 



http://www.ebooks.kluweronline.com 

http://www.springeronline.com 



Contents 



Preface 




ix 


Contributing Authors 


xi 


Introduction 
F. Kordon, M. Lemoine 


xvii 


1 


The “Traditional” development approach 


xvii 


2 


What is covered in this book 


xviii 


3 


Organization of chapters 


xviii 


Part I 


The BART Case Study 




1 

The BART Case Study 
V. Winter, F. Kordon , M. Lemoine 


3 


1 


Introduction 


3 


2 


Objective 


3 


3 


General Background on the BART Train System 


4 


4 


Informal Specification for the AATC System 


5 


5 


Inputs and Outputs to the Control Algorithm 


8 


6 


Physical Performance of the Train in Response to Commands 


10 


7 


Worst Case Stopping Profile 


11 


8 


Considerations with Acceleration and Speed Commands 


16 


9 


Quantitative Quality and Safety Metrics to be Demonstrated 


17 


10 


Vital Station Computer (VSC) Issues 


18 


11 


Miscellaneous Questions and Answers 


19 


Part II 


Building and Validating Conceptual Aspects 




2 

Formal Specification and Refinement of a Safe Train Control Function 
V. Winter D. Kapur G. Fuehrer 


25 


1 


Introduction 


25 


2 


Technical approach and method 


28 


3 


Inputs taken from the BART case study 


38 


4 


Applying the approach to the case study 


42 


5 


Results raised by this technique 


56 


6 


Conclusion 


57 



V 




VI 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



1 


Appendixes 


60 


3 

From UML to Z 
M. Lemoine, G. Gaudiere 


65 


1 


Introduction 


65 


2 


Technical approach and method 


67 


3 


Our approach in details 


72 


4 


Inputs taken from the BART case study 


80 


5 


Applying the approach to the case study 


81 


6 


Results raised by this technique 


86 


7 


Conclusion 


87 


4 

Environmental Modeling with UML 
Adrician De Groot, Jozef Hooman 


89 


1 


Introduction 


89 


2 


Technical approach and method 


92 


3 


Applying our approach to the case study 


102 


4 


Designing a Controller 


116 


5 


Results raised by this technique 


127 


6 


Conclusion 


127 



Part III Building and Validating Operational Aspects 



5 

Checking BART Test Scenarios with U M L’s Object Constraint Language 133 

M. Gogolla, P. Ziemann 

1 Introduction 133 

2 Technical approach and method 135 

3 Inputs taken from the BART case study 147 

4 Applying the approach to the case study 149 

5 Results raised by this technique 166 

6 Conclusion 169 



Modeling and verifying behavioral aspects 171 

F. B reant, J.-M. Couvreur, F. GiUiers, F. Kordon, I. Mounier, E. Paviot-Adet, D. Poitre- 
naud, D. Regep, G. Sutre 



1 Introduction 

2 Technical approach and method 

3 Inputs taken from the BART case study 

4 Applying the approach to the case study 

5 State space computation using DDD 

6 Conclusion 



171 

172 
187 
191 
195 
209 



Part IV Methodological Aspects 
7 

AlltoFoCUS - Mastering the Complexity 215 

B. Schatz 




Contents 



vii 



1 Introduction 

2 Technical Approach and Method 

3 Inputs taken from the BART case study 

4 Applying the approach to the case study 

5 Results raised by this technique 

6 Conclusion 

8 

Conclusions 259 

F. Kordon, M. Lemoine 

1 Are Formal Methods an appropriate answer to the Design of Dis- 
tributed Systems? 259 

2 A process for the Design of Safety Critical Distributed Systems 262 



215 

216 
226 
227 
254 
256 




Preface 



The development of any Software (Industrial) Intensive System, e.g. critical 
embedded software, requires both different notations, and a strong develop- 
ment process. Different notations arc mandatory because different aspects of 
the Software System have to be tackled. A strong development process is 
mandatory as well because without a strong organization we cannot warrantee 
the system will meet its requirements. Unfortunately, much more is needed! 

■ The different notations that can be used must all possess at least one 
property: formality. 

■ The development process must also have important properties: a exhaus- 
tive coverage of the development phases, and a set of well integrated 
support tools. 

In Computer Science it is now widely accepted that only formal notations can 
guarantee a perfect defined meaning. This becomes a more and more important 
issue since softw are systems tend to be distributed in large systems (for instance 
in safe public transportation systems), and in small ones (for instance numerous 
processors in luxury cars). Distribution increases the complexity of embedded 
software while safety criteria get harder to be met. 

On the other hand, during the past decade Software Engineering techniques 
have been improved a lot, and arc now currently used to conduct systematic and 
rigorous development of large softw are systems. UML has become the de facto 
standard notation for documenting Software Engineering projects. UML is 
supported by many CASE tools that offer graphical means for the UML notation. 
Moreover CASE tools arc able to generate code templates and support round 
trip engineering between class diagrams and program code. However, all case 
tools and more generally the Software Engineering techniques used in practice 
do not well support the early phases of software development. They still lack 
analysis and validation means for requirements and design specifications which 
arc easily connected to the implementation phase, even when UML is used in 
conjunction with some process, such as the RUP or Fusion (see references 
further). 
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Formal techniques have undergone a steep development during the last years. 
Based on formal foundations and deep theoretical results, methods and tools 
have been developed to support specification and design of software systems. 
Model-based and algebraic specifications, abstract state machines, CSP and 
CCS, temporal logics, rewriting techniques, finite automata, model checking 
and many other formal specification and verification techniques have been ap- 
plied to non-trivial examples and arc used in practice e.g. for the development of 
safety critical systems. Nevertheless Software Engineering practitioners claim 
that formal notations arc not scalable enough. 

This main drawback was the topic of a Dagstuhl seminar organized in May 
2001 (seminar # 01221) by S. Jahnichen (Technical University of Berlin and 
Fraunhofer Institute, Berlin-Ge), J. Kramer (OPEN University, London-UK), 
M. Lemoine (ONERA, Toulouse-F) and M. Wirsing (Technical University of 
Miinchen, Munich-Ge). This workshop gathered a set of selected academic 
people to discuss the following problem: "Can Formal Methods Cope with 
Software-Intensive Systems?" For these discussions, the "BART case study" 
(see Chapter 1) was suggested as a common basis to check how far the formal 
methodologies promoted by the represented teams could be efficiently applied. 

Based on works presented in this seminal - , a few presentations have been 
selected. They are the basis of the following chapters. The result is the book 
you are handling right now. 

We would like to thank all the authors for the work they accomplished for this 
book. We also want to thank M. De Jong and C. Zitter, from Kluwer Academic 
Publisher, for their continuous help and encouragements all over the process. 



F. Kordon, M. Lemoine 
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Introduction 

F. Kordon, M. Lemoine 



1. The “Traditional” development approach 

Let us consider the traditional development approach for computer-based sys- 
tems. This approach can be represented by the well known “V” software life 
cycle model, as shown in Figure 1.1. 




Figure 1.1. The traditional V life cycle. 

This software life cycle put emphasis on a tactical view of the development 
activity: the one that aims at producing “something” on time. 1 The first part 
of this approach is top-down. After having defined the requirements, their arc 
analyzed. A solution is then elaborated: general design before the detailed one. 

The coding activity corresponds to the end of the first paid in a product 
development. Programs arc then tested (unit per unit), integrated, i.e. assem- 
bled, tested again (component by component up to the complete application). 
Deployment to the clients’ sites is possible and maintenance can staid. 

xvii 
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2. What is covered in this book 

There are thousands of possible interpretations of this software life cycle (this 
is the same for other life cycles too). However, developing software becomes a 
much more delicate task since it comes to distributed applications, or embed- 
ded, or both. In that context, formal-based methods and techniques bring an 
increased level of security. The drawback is their complexity to set up and use. 

This book is dedicated to the presentation of some techniques to be used in 
the context of distributed and/or embedded systems. Since formal techniques 
rely on models, i.e. different descriptions of the system to be designed, the 
presented techniques are located in the first paid of software development, as 
shown in Figure 1.2. 




Figure 1.2. Objectives of this book in the V-cycle. 

We do not deal with implementation aspects. Since code generators from 
specifications (like with HOOD or, more recently, with UML) are now widely 
accepted and used (event if the generated code requires to be enriched), it is 
obvious that the use of such tools is required for coding. Otherwise, manual 
implementation may lead to a derive due to misunderstanding of the initial 
system (or the integration of implementation hypotheses). But this is again out 
of the scope of this book. 

3. Organization of chapters 

The problem of complex systems is to provide a safe implementation, and, prior 
to this, a safe design. For distributed and/or embedded systems, this mainly 
asks the following questions: 

■ Is the system complete or, in other words, does it fulfill all its require- 
ments? 
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■ Is the system behavior understood or, in other words, can the system 
behave erroneously? 

This is why the book is divided in two parts. A first one deals with “Con- 
ceptual” aspects (i.e. understanding of the requirements, appropriateness of the 
design, etc.) and“behavioral” aspects. 




Figure 1.3. Where chapters refer to in the V cycle. 

Figure 1.3 approximately locates which phases of the software life cycle arc 
considered by the methods presented in the following chapters. 

How to read this book? We have decided to split the book into 4 main parts. 

Part I is mainly concerned with the BART Case Study. It contains only one 
chapter: the BART case study that is a common base to all chapters. Indeed 
all the presented techniques have used it as their application. Proceeding this 
way will allow the reader to identify where, in software life cycle, they can be 
(re)used, and of course to compare them, from a notational point of view. 

The reader is recommended to read the first chapter as carefully as she/he 
can. Indeed you will find a Requirements Document as the Industry is used to 
deliver. Rigorous needs corresponding to end users’ wishes, strong constraints 
corresponding to well defined obligations the system must meet arc expressed 
in natural language. Moreover the authors of the Requirements Document have 
presented it as numbered paragraphes. This numbering can be used to build a 
traceability matrix between informal requirements and formal ones, as they arc 
introduced in the other chapters. 

Part II is intituled “Building and Validating Conceptual Aspects”. 

■ Chapter 2 is the description of a specification language that helps devel- 
oping and analyzing reactive systems that must meet constraints such as 
safety and optimality. Moreover, the specification can be transformed 
into ML codes, and then run as prototypes. Transformations can be 
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proved as safe, allowing then to refine it and to arrive to a more efficient 
implementation. 

■ Chapter 3 is much more concerned with Requirements Engineering. It is 
shown how an Informal Requirements Document can be transformed into 
semi formal and formal models. An incremental process is suggested to 
both specify rigourously the system as set of static models, and then to 
validate them formally. UML as semi formal notation and = Z as formal 
one arc homogeneously integrated in a specific Evolutionary process. 

■ Chapter 4 is much more classic. It refers to one possible way of using 
UML for specifying reactive systems, and to the use of some formal 
notation to check with a theorem prover how statecharts arc right. 

Part III intituled “Building and Validating Operational Aspects” contains 2 
chapters. 

■ Chapter 5 shows how some UML design can be checked efficiently using 
OCL as specification language, and USE as support tool. The result is a 
set of scenarios that can be played, and replayed as long as necessary, to 
convince end users of the quality of the formal specification of the system 
under consideration. 

■ Chapter 6, even rather similar to Chapter 5, puts the emphasis on a for- 
mal graphical Architectural Description Language, which allows both 
to integrate static and dynamic aspects of any reactive system. As main 
result, the built formal models can be both formally analyzed, and as well 
prototyped. 

Part IV is intituled “Methodological Aspects”. It contains one and only one 
chapter. 

■ Chapter 7, as expected in a methodological paid, presents the AutoFocus 
approach, which is real methodology. In other words a dedicated process 
is introduced, with some notations, and some supporting tool. It can be 
considered as a summary of what could be done if we expect to develop 
a safe and secure system. 

The last chapter introduces the conclusion, which is nothing more than the 
view of the authors, regarding the techniques and methodology used to specify 
the BART system. 

Notes 

1. Other“life cycles” put emphasis on maintenance (spiral), on components, on knowledge reuse 

Their description is out of the scope of this book. 
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Chapter 1 



The BART Case Study 



V. Winter*, 
F. Kordon, 
M. Lemoine 



Abstract This chapter describes the BART case study, that will be used in all this book 
as a common problem to be solved by various analysis methods. The follow- 
ing chapters pick-up pieces from this example to illustrate possibilities of the 
presented techniques. 



1. Introduction 

This document originally comes from [WB01], It has been written by Victor L. 
Winter, Raymond S. Berg and James T. Ringland from Sandia National Labora- 
tories. The corresponding work was supported by the United States Department 
of Energy under Contract DE-AC04-94AL85000. Sandia is a multiprogram 
laboratory operated by Sandia Corporation, a Lockheed Martin Company for 
the United States Department of Energy. 

2. Objective 

1 This document contains an informal description of a portion of the Advanced 
Automatic Train Control (AATC) system being developed for the Bay Area 
Rapid Transit (BART) system. BART provides commuter rail service for part 
of California’s San Francisco bay area. Specifically, the informal specification 
given below focuses on those aspects of BART that arc necessary to control the 
speed and acceleration for the trains in the system. Other aspects of BART 
control such as (1) communication error recovery, (2) routing (via switches) 
and (3) right-of-way signaling (via “gates”) arc largely ignored. The scope of 
this case study is narrower than the AATC project as a whole, but within this 



* Chapter responsible. 
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narrowed scope, enough detail has been supplied to give a sense of the level of 
complexity involved. 

2 The overall objective of this case study is to construct a system (software or 
otherwise) within the infrastructure given, that can control the speed and ac- 
celeration of trains in the system subject to the various constraints that arc 
described in the specification. In particular, it is not the purpose of the case 
study to criticize the infrastructure. 

3 You arc asked to present your research in the context of this case study. Specif- 
ically, how would your work positively impact the construction of the speed 
and acceleration control system? Also, since the purpose of this case study is 
to provide a context for presenting your research, it is perfectly acceptable to 
make simplifications when necessary. And finally, the informal specification 
given will no doubt contain ambiguities. Again, given that this is an academic 
exercise, feel free to resolve any ambiguities in whatever manner seems most 
reasonable to you. 

3. General Background on the BART Train System 

4 It is not assumed that those participating in this case study have an extensive 
knowledge of train systems and terminology. This section gives a general 
overview the BART train system. 

5 BART provides heavy commuter rail service in the San Francisco Bay Area. 
On a typical work day it serves around 250,000 passengers. During commute 
hours over 50 trains, most consisting of 10 cars, will be in service. Cars arc 
driven by electric motors powered by a 1000 VDC, “third rail.” Cars use both 
regenerative and friction brakes. The system is controlled automatically. On- 
board operators have a limited role in normal operations. Operators signal 
the system when the platforms arc clear so a train can depart a station. More 
importantly, operators trouble-shoot problems, and can operate trains manually 
(at low speeds) when there is a problem. 

6 The system operates most of the day, but there is some maintenance time avail- 
able at night. Trains run on the BART system from 4:00 AM, when the first 
trains leave the yards to position themselves for the day’s service, until about 
1:30 AM, when the last trains return to the yards. On Sunday mornings, trains 
leave later: around 7:00 AM. 

7 With a few minor exceptions, the BART system consists of double track: one 
track going one direction and one track going the other. The trains go from 
a starting point to an ending point (i.e., the track is not a loop.) As discussed 
later, there is an AATC controller at the front and back of each train (consist). 
At the end of the line, the front and back controllers arc redefined and the train 
goes in the other direction. 
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8 As the map Figure 1.1 shows, the lines feed from points north, south and east 
into San Francisco, with the critical link being the section from Oakland to 
points west where four lines share one pair of tracks. To serve more passengers, 
BART needs to utilize this section more efficiently. Adding new tracks to this 
segment - in a tube under the bay and underground in the heart of San Francisco 
- would be prohibitively expensive. BART needs to run trains more closely 
spaced. AATC will allow them to do that. 
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Figure 1.1. The map of the BART transit system. 

9 A track is partitioned into track segments. Track segments may be bounded 
by gates. A gate can be viewed as a traffic light of sorts, where a closed 
gate corresponds to a red light and an open gate corresponds to a green light. 
Gates establish the right-of-way where tracks join or merge at switches. The 
purpose of gates is to keep trains from passing through switches before they 
arc appropriately positioned. Gates not associated with switches can be used 
to control traffic how. 

4. Informal Specification for the AATC System 

1 0 The AATC system replaces paid but not all of BART’s current control system. 
AATC consists of new station computers, a radio communications network 
that links the stations with the trains (communications currently arc through the 
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running rails, with very low bandwidth), and software modifications to the front 
and back controllers on-hoard the trains. The communications system provides 
ranging information (from wayside radios to train radios and back) that allows 
the system to track train positions. On the trains, the control computer is located 
in the lead car. This computer controls the operations of the brakes and motors 
on all the cars in the consist. 

11 Most of the control computation is done at the stations; the trains respond 
to speed and acceleration commands. Each station controls trains only in its 
immediate area. A station must thus communicate with its neighbors to receive 
and hand-off trains. BART has asked its contractors to size the system to be 
able to handle 20 trains in each station’s control zone. This would correspond 
to an extreme back-up situation. In locations where stations arc closely spaced, 
such as in downtown Oakland or San Francisco, one computer may manage a 
zone that spans several stations. 

1 2 This case study will concentrate on one of the most critical functions of the new 
station computers - calculation of the speed and acceleration commands that 
arc sent to the trains. For this study we will assume that the communications 
link, the on-hoard train control system, and station computer functions other 
than speed and acceleration selection work as intended. The latter include 
conversion of ranging data into train position estimates, managing entry and 
exit of trains into the system, and hand-offs between stations. 

13 The other major aspect of train control is interlocking - the management of 
track switches and associated signals to enter or not enter whole blocks of 
track. (In the 19-th century, track switches and flags to signal train operators 
were mechanically interlocked. The name has stuck.) At BART interlocking 
is handled by another system that is not being replaced as paid of the AATC 
development. The AATC system will simply see “go” or “stop” indicators at 
various track locations in the system. A train should enter such a location (i.e., 
a “gate”) only if allowed. Otherwise it should stop before the gate if it can. (It 
is the responsibility of the interlocking system not to move a switch if a signal 
change occurs when it is too late for an approaching train to stop. The system 
interlocking may, however, “close” a gate at any time as a signal to following 
trains.) Stopping at a station platform is much like stopping in front of a gate, 
although there arc some additional controls (not discussed here) to assure the 
final stop is at precisely (within about a foot) of the desired location. 

1 4 The responsibility of the speed and acceleration selection process is to get trains 
from one point to another as fast and smoothly as possible, subject to various 
constraints. These constraints include: 

■ A train should not enter a closed gate. 

■ A train should never get so close to a train in front that if the train in front 
stopped suddenly (e.g., derailed) the (following) train would hit it. 
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■ A train should stay below the maximum speed that segment of track can 
handle. 



15 This is a simplification - this case study is omitting many details with which 
system designers must deal. 

16 The AATC system operates on 1/2-second cycles. Each half-second the station 
computer receives ranging and - speed information (derived from tachometer 
data) from the trains. It uses that information to compute an uncertainty en- 
velope for the location of each train (mean and standard deviation). For this 
study, assume this function works as intended and provides fully reliable inputs 
to the speed/acceleration selection problem. This information, along with track 
signal and track layout information, is used to compute speed and acceleration 
commands. 

1 7 Commands are time stamped and become invalid 2 seconds after the identified 
time. This time stamping (or time tagging) is done by what is called a Message 
Origination Time Tag (MOTT). When a train sends performance data back to 
the station, it attaches the time that it sends (originates) the message. When 
that information is used to update the position estimate, the MOTT is associ- 
ated with that position estimate. The time stamp provides a measure of the 
currency of a position estimate. When that position estimate is used to compute 
a speed/acceleration command, that MOTT is attached to the command. The 
train then checks the MOTT before exercising a command. A train will con- 
tinue to exercise that command until a new one arrives or until that command 
expires, 2 seconds after the originating time. 

1 8 If the train does not have a currently valid command, it goes into maximum 
braking. The control algorithms thus have to be designed so that if all com- 
munications arc lost, then when commands expire and trains come to a stop, 
no safety violations will have occurred. That is, the stopping location of any 
train after lost communications, has timed out, and has come to a stop will be 
(1) behind any closed gates and (2) behind the real - end of any trains ahead. 
This sequence of events, along with a very pessimistic definition of how long 
it physically takes to stop a train once braking begins, defines what is called 
the “Worst Case Stopping Profile.” Similarly, the control algorithms have to be 
designed so that whatever happens, the train must not exceed any track speed 
limits. 

19 The station computer itself is divided into two systems. First is the Non- Vital 
Station Computer (NVSC). (“Vital” in the context of railroad safety can be 
interpreted to mean that the function is critical to the safety of the system.) 
The NVSC is a fast, flexible computer. The hardware is reliable enough to 
meet performance-driven Mean Time Between Failure (MTBF) and Mean Time 
Between System Shutdown (MTBSSD) goals but not safety-related Mean Time 
Between Hazard (MTBH) goals. These goals are defined precisely below. 
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Second is the Vital Station Computer (VSC), which is slower but reliable enough 
to meet safety-related MTBH goals. 

20 The NVSC proposes speed and acceleration commands, considering both safety 
and performance goals. The VSC checks that they do not exceed maximum 
bounds for safety. For smooth operations, the NVSC generally will have to 
propose speeds and accelerations lower than the absolute maximums against 
which the VSC checks. For this case study, you may partition functions among 
the two machines as you wish, subject to meeting overall safety goals, the fact 
that the NVSC hardware alone cannot support these goals, and the VSC cannot 
do more than essentially one computation of a bounding speed and acceleration. 

21 Note, This description of the NVSC and VSC does not precisely represent 
the actual interaction between the two machines being designed for the AATC 
system. The discussion above captures the basic concepts, but omits some real 
[and proprietary] system design complexities. 

22 The following sections provide some additional details about the control system. 

5. Inputs and Outputs to the Control Algorithm 

23 The control algorithm receives the following information, updated every 1/2 
second. 

■ The outputs of the position algorithm - mean and standard deviation on 
both position and velocity - for all trains in the area. Nominal performance 
for the system is for the standard deviation to be 2 to 3 feet. Note that 
both the mean and standard deviation will vary a little (e.g., a few feet) 
from each | -second-time step to the next. 

■ The Message Origination Time Tag (MOTT). This is the time a given train 
sent its most recent report. Information from this report is folded into the 
position tracking system. Thus the MOTT is a measure of information 
currency. After receiving a MOTT from a train, the control system then 
attaches the same MOTT to acceleration and velocity commands that arc 
then sent back out to the train, and the commands are only valid until 
MOTT + 2 seconds. 

■ Gate information (open, closed) from the Interlocking system. 

■ Any special speed restrictions on either the whole system or individual 
track segments. 

24 It is the responsibility of the control system to separate trains sufficiently so that 
if a train in front instantaneously stopped (e.g. it derailed) then the following 
train could stop without hitting it (assuming worst-case conditions). Addition- 
ally, if a “leading train” (one in front of the train for which a speed/acceleration 
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command) stops sending reports back to the station, the algorithm has to as- 
sume it is in the location associated with its last report (e.g., the train could 
have just derailed). And finally, it is the responsibility of the control system 
to prevent a train from entering a closed gate if it can. As noted earlier, it is 
the responsibility of the interlocking system not to move a switch if a signal 
change occurs when it is too late for an approaching train to stop. The system 
interlocking may, however, “close” a gate at any time as a signal to following 
trains.) 

25 The following static data is also available for segments of the track. Segment 
location (end points and length) 

■ Grade (less than 4% system-wide). Each track segment has only one 
defined grade. Grades can either be constant or be paid of a parabolic 
change from one grade to another. 

■ Maximum allowable speed. (Maximum speeds typically range from 36 
to 80 mph, with some lower numbers on crossovers and siding.) It is the 
responsibility of the control systems to slow trains down before entering 
segments with low allowable speeds. 

■ Locations of gates (at ends of some segments) 

26 The table at the end of this informal specification gives a sample of the sort 
of information in the track database. This sample covers paid of western San 
Francisco, from the Daly City station to the 24-th Street Mission stations. Be- 
tween these arc the Balboa Park and Glen Park stations. (See the map earlier 
in this write-up.) In this particular example, one station computer controls the 
entire area from a point about half way between Daly City and Balboa Paid to a 
point about half way between Glen Park and 24-th Street. That is, one station 
computer is actually controlling the area around two stations. 

27 The control algorithm then must produce for each train, a command message. 
All processing for all trains must be complete at the end of the 1/2-second cycle. 
That message contains the following safety critical data: 

■ ID of the train for which the command is intended. 

■ Commanded speed (between 0 and 80 mph). 

■ Commanded acceleration (-2 to -0.45 mphps in (closed loop) braking, 0 
to 3 mphps in propulsion). 

■ Message Origination Time Tag. 

■ A fixed four bit code identifying this as a command message. 

28 Some non-safety-critical information is also sent. 
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6. Physical Performance of the Train in Response to 
Commands 

29 When given a speed and acceleration command, the train will accelerate to 
2 mph under the commanded speed at the indicated acceleration. Maximum 
propulsion rates depend on speed. At low speeds, up to 31 mph, accelerations 
as high as 3 miles per hour per second (mphps) on flat track are possible. At 
higher speeds, only lesser accelerations arc possible. In practice, BART uses 
a look-up table to get exact values, but for reference, at 80 mph, accelerations 
of only 0.78 mph arc possible. 80 mph is the maximum speed that the control 
system can send to the train. When the actual speed is within 7 mph of the com- 
manded speed, the train controller will limit maximum allowable accelerations 
to smoothly reach a speed 2 mph below the commanded speed. (Note that the 
train controller is a system that is separate from the control system.) Once a 
speed of 2 mph below the commanded speed is achieved, the train will attempt 
to maintain that speed, although there may be some small fluctuations (on the 
order of ±1 mph). The train can coast while in propulsion mode. Rolling 
friction and wind resistance can then reduce train speed, except perhaps on 
down-grades. 

30 The intent of maintaining an actual speed 2 mph below the commanded speed 
is to ensure, given these fluctuations, that the actual speed not exceed the com- 
manded speed. The train will initiate braking to prevent speeds in excess of the 
commanded speed, as might be the case on a downgrade. As will be discussed 
below, it takes a little time for the train to move from propulsion mode into 
braking mode. Doing so frequently results in a jerky ride for the passengers 
and excess wear on the equipment. Seeking to maintain a speed 2 mph below 
the command speed limits but allowing for small fluctuations minimizes mode 
changes. 

31 Trains have two different braking modes. In open-loop (maximum) braking 
the train simply attempts to brake at its maximum rate, 3 mphps. The trains 
arc designed to revert to open-loop braking unless a DC signal is continuously 
applied to inhibit it. Thus, in the case of control failure, the trains should stop 
safely. In closed-loop braking, less than maximum rates can be applied and 
those rates can be continuously varied. 

32 The maximum brake rate may not be achievable in practice. If wheel slippage 
is detected, the controls to that set of wheels reduces the braking force so that 
wheel adhesion can be regained. Wheel adhesion and slippage limits, not the 
capabilities of the braking system, often determine how fast a train can stop. 
The worst case profile to be discussed below assumes only decelerations of 
1.2 mphps on wet track and 1.6 mphps on dry track, although these are very 
pessimistic bounds. 
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33 Adhesion can also limit acceleration performance, although this is not critical 
for safety. Note also that when the wheels are slipping, tachometer data will 
not be representative of real speeds. 

34 The minimum brake rate is 0.45 rnphps. 

35 There are delays in moving from propulsion into braking and in changing brake 
rates. It takes 1.5 seconds to move from maximum propulsion to coasting and 
1 second to reconfigure while coasting from propulsion mode to braking mode 
(the same timings are true when going in the reverse direction). Brake rates 
(d 2 x/dt 2 ) then ramp up with a jerk rate (d'’ , x/dt >> ) of -1.5 miles per hour per 
second per second. 

36 Likewise, there are delays in changing brake rates or moving from braking 
into propulsion. Again brake rates can be changed subject to a jerk rate of 
1.5 mphpsps. There is a 1 second mode change. Propulsion acceleration can 
change with jerk rates of 2 mphpsps. 

37 Grades will change actual accelerations. For the purposes here, this case study 
will assume that all potential energy is converted to kinetic energy (or vice 
versa) on grades. This will affect the acceleration limits due to motor or brake 
performance. 

7. Worst Case Stopping Profile 

38 One fundamental safety requirement is that train speeds and accelerations be 
selected so that (1) the train does not hit a train in front of it or (2) enter a closed 
gate. These safety requirements must be satisfied even in the case of very poor 
stopping conditions. 

39 A profile defining a “worst-case” stopping distance of trains has been agreed 
upon. While this profile does not represent the absolute limit of what could 
happen, it does represent a very conservative bound. The use of this profile as a 
worst-case bound was approved by the California Public Utilities Commission 
Interim Order of June 3, 1980. Thus, performance of a train that is worse than 
this profile - which is theoretically possible but extremely unlikely - represents 
a publicly agreed upon, accepted risk. 

40 Train stopping performance is limited by the time it takes to move into full 
braking, and then, once in braking, the adhesion of the train wheels to the track. 

41 The Worst Case Model assumes the velocity distance profile shown in the fig- 
ure on page 12. This figure assumes the train is configured for propulsion or 
speed maintaining and that the track grade is constant throughout the stop. The 
stopping distance is the sum of D\ through D~ as shown at the bottom of the 
figure. The length of each segment is based on worst case assumptions. 

42 Figure 1.2 starts with a train speed maintaining at the commanded speed ( Vcm ) 
with a command that is time-tagged at the time when the train is located at 
position L;. The control algorithms cannot know exactly where L, is since train 
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position is reported only with an estimated mean and standard deviation. The 
first segment of the worst case profile, D\ accounts for this uncertainty. That 
command is valid for 2 seconds after that tagged time. If the train receives no 
further commands, then after 2 seconds, the train will enter maximum braking. 
If a new command is received, it will act on that command. If the new command 
calls for braking, then the train will initiate the braking sequence at that time. 
Thus, the latest response to an obstacle occurs if the train waits 2 seconds 
and then “times out”. D -2 is the distance the train would travel during those 2 
seconds. 




Detanc* 



Worst Case Model -Train accelerating or maintaining speed 
Constant Grade 



Figure 1.2. Worst case model in the BART system. 

43 When the train reacts to the need to stop at the beginning of /><, the agreed-upon 
worst case model assumes that the train suddenly is in full propulsion (a non- 
physical bounding assumption). The train then has to stop propulsion (D3 - it 
takes 1.5 seconds to move from full propulsion to no propulsion), reconfigure 
for braking (D4 - it takes 1 second to reconfigure), and then apply the brakes 
( Dr, - it takes up to 1.5 seconds to apply the brakes, although the actual time 
depends on the brake rate). Because of details in the operation of the train 
brakes, the worst-case model assumes that initially a train has only 60 percent 
braking capability (e.g., the brakes arc not responding in 40% of the cars in the 
train). With respect to the non-braking cars (i.e., 40% initially) it is assumed 
that half of these cars (20% of the total train) will recover 8.5 seconds after 
the beginning of D3. (This accounts for the possibility that some cars may not 
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respond to the command to reconfigure for braking, but will successfully go 
through a back-up “fail-safe mode change.” This will force the cars in question 
into braking mode, but there is some additional delay. The worst case model 
assumes that the other half of the malfunctioning cars (20% of the total train) 
never contribute to braking. (This worst-case bound covers total brake failures, 
locked up (skidding) wheels, and transient brake drop-outs.) 

■ D i : This distance accounts for the uncertainty (e.g., 6 sigma) of the train 
position from the perspective of the control system. 

■ Do: In the case where no command is received (e.g., a time out = 2 
seconds maximum), D2 denotes the worst case distance that could be 
travelled before a time out. 

■ D3 : This is the distance that the train would travel while the train switches 
from full acceleration mode to coasting mode. At this point it is assumed 
that the train (suddenly) is in full acceleration mode. This is a non- 
physical worst case bound. 

■ Dp This is the distance that is travelled while the train switches from 
coasting in propulsion mode to braking mode. 

■ D5: The distance travelled before the brakes fully ramp on. 

■ Dq : This is the distance that is travelled while 60% of the cars arc braking 
and 40% arc not. 8.5 seconds after the beginning of D3, the train achieves 
80% percent braking. The model assumes 20% of the cars go through a 
slower fail-safe mode change to reconfigure for braking. 

■ D7: At this point we have 80% of the cars braking normally and the 
remaining 20% of the cars do not contribute to the braking. D7 represents 
the distance required for the train to come to a complete stop. 

44 The equations for calculating D\ through D7 arc shown in the shaded tables on 
the next pages. 

45 An item of interest is that distance D 3 is non-linear with velocity because the 
acceleration rate A p decreases with increasing velocity. (The actual values 
involve a lookup table, but the values range from 3 mphps at train speeds under 
31 mph to .78 mphps at 80 mph. However, the jerk time does not change. 

46 The design brake rate in D7, depends on whether the track is exposed (open 
to the elements) or covered (in tunnels). Exposed track may be wetter. The 
wheels may begin to slip at lower speeds on exposed track than on covered 
track. About 1/3 of the BART system is underground. 

47 In practice, trains may be commanded to decelerate at less than the maximum 
rate. The worst-case stopping profile once a train is in braking (but at less than 




14 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



full rate) omits intervals />; — Dg. Interval D\ applies unchanged. Interval D 2 
applies, but one can assume the train is decelerating at the minimum brake rate 
of 0.45 mphps. (For the worst-case calculation, we assume pessimistically that 
only minimum braking is applied.) 
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Table 1.1. Worst case train calculations 



48 In handling stops of varying grades, BART has developed some rather lengthy- 
to-describe heuristics. The physical facts are relatively simple. Track grades 
can be represented either as being of constant grade : x feet at one grade, y feet 
at another grade, or as part of a parabolic transition from one grade to another. 
On grades, potential energy is exchanged for kinetic energy: mgh = 1/2 mv 2 . 
The tables give the formulas appropriate for constant grades. One cannot, 
however, just easily subdivide the stopping profile into smaller segments where 
the grade is constant. Trains arc not point masses. A full train is 710 feet 
long. The potential energy of a train is constantly varying. (For the purposes of 
the case study, you may either assume constant grades, accept that a reasonable 
approximation exists, or work out and solve the actual, moderately complicated, 
differential equations. However, BART has found that their heuristics, for the 
actual track at hand, arc fully adequate.) 

49 For these worst-case safety-related calculations, the effects of rolling friction 
and wind resistance (which arc real) arc not included. 
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NOSE 


def 

def 


Estimated train nose location (ft) 
(from Update Position Algorithm) 


PUF 


Uncertainty Factor = 6 


PU 


def 


Position Uncertainty reported as 
one standard deviation (ft) 


V CM 


def 


Commanded Speed (mph) 


AD 


def 


AATC Delay = 2 seconds 


Jp 


def 


Jerk Limit in Propulsion 

(Function of Speed and Grade) (mphps ps) 


Ap 


def 


Acceleration in Propulsion 
(Function of Speed and Grade) = mphps 


Tjp 


def 


Jerk Time in Propulsion =1.5 Seconds 


A 


def 


Acceleration Due to Grade = -21.9 mphps * Gra ^“ % 


MC 


def 


Mode Change = 1 Second 


NCAR 


def 


Number of Cars in Consist = 10 Cars 


NFAIL 


def 


Number of Failed Cars = 2 Cars 


NFSMC 


def 


Number of Cars In FSMC = 2 Cars 


Jb 


def 


Jerk Limit in Braking = -1.5 mphps ps 


BRK 


def 


Design Brake Rate = -1.5 mphps for exposed track; 






-2.0 mphps for covered track 


FSMC 


def 


Fail Safe Mode Change Time = 8.5 Seconds 



Table 1.2. Worst case train parameters 
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8. Considerations with Acceleration and Speed 
Commands 

50 As noted in the introduction, actual speeds and accelerations must be consistent 
with worst-case safety bounds and must never allow a train to exceed an allow- 
able maximum speed. Once these are met, there arc secondary performance 
objectives. These include the following: 

■ Minimize the time travelling from station to station. (Schedules can be 
maintained by dispatching trains appropriately and holding in stations if 
need be.) 

■ Avoid large and frequent changes in speed and acceleration. This max- 
imizes passenger comfort, provides minimal stress on equipment, and 
minimizes power usage. 

■ Avoid mode changes. (Note coasting can be done in propulsion mode.) 

There arc two concerns when accelerating a train from a lower speed to a higher 
speed in an area where trains arc close to one another. 

■ Spacing trains farther apart than necessary because the commanded ve- 
locity (which is used in the worst case stopping distance calculation) is 
much greater than the actual velocity. 

■ Accelerating a train so fast that it nears infringing on the worst case 
stopping distance and must go into braking. 

51 Regarding the first, note that worst case stopping distances arc calculated using 
the commanded speed, not the actual speed, so commanded speeds should 
not be too much greater than the actual speed. Conversely, since the train 
automatically limits accelerations when within 7 mph of the commanded speed, 
the commanded speeds should not be too close to estimated speeds. 

52 Regarding the second, when a train is accelerating behind another train which 
is also accelerating and is located close to the worst case stopping distance of 
the following train, the speed of the following train will tend to oscillate. The 
oscillation occurs because the stopping distance increases with the square of 
the velocity while the velocity of the following train increases linearly with 
acceleration. The following train will accelerate to nearly within the worst case 
stopping distance, brake, and then repeat the cycle. This is undesirable. In 
order to avoid this oscillatory behavior, it is necessary to maintain a separation 
distance between the two trains that is greater than the worst case stopping 
distance of the real - train throughout the acceleration profile and to choose 
acceleration rates judiciously. 

53 Uncertainties in position estimates can lead to some irregularities in the worst 
case stopping distance from one 1/2-second cycle to the next. If the position 
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uncertainty envelope grows a little bit or if the best location estimate varies a 
little bit within the uncertainty bound, a train that was a little bit outside the 
worst case stopping distance of an obstacle could suddenly (and artificially) 
find itself within the worst case stopping distance. The appropriate response at 
this point is to go into braking. And then perhaps at the next cycle the train may 
find itself a little bit outside the worst case distance, so braking is no longer 
needed. This too produces an undesirable oscillation. 

54 The acceleration from gravity on a non-zero grade adds to the acceleration/dece- 
leration rates. The vehicle controllers use data from accelerometers as feedback 
when controlling train acceleration. If the train is accelerating or decelerating at 
a constant rate due to gravity, the accelerometers will not sense that acceleration. 
They will sense only additional acceleration supplied by brakes or motors. Thus, 
if the train is asked to accelerate at 1 mphps on a downgrade, it will actually 
accelerate at 1 mphps — ( Gra ioo n % )*(21.9 mphps [Note 21.9 mphps = 32.1 
fpsps = g = gravitational acceleration.). The train does not know the grade it is 
on. Any corrections for this effect have to be done by the station computer. 

55 Similarly, velocity commands to a following train should not lead to oscillatory 
behavior. In a simple case with a following train within the stopping distance 
plus a some margin of another train which is speed maintaining, the following 
train should not be given a velocity command that is much above the speed of 
the lead train as the margin narrows. 

9. Quantitative Quality and Safety Metrics to be 
Demonstrated 

56 In addition to the system performance issues discussed above, there arc several 
qualitative quality and safety metrics to be demonstrated. The metrics arc to be 
computed system-wide, assuming 26 control stations, 72 miles of double track, 
and 160 AATC-equipped vehicles (80 trains in service). 

57 The Mean Time Between Hazard must be more than 1,000,000,000 hours (i.e., 
10 9 hours) system- wide. For this case study, a “hazard” is one of the these three 
conditions: 

■ A train being physically within the worst-case bounds of any obstacle 
such as a closed gate or the rear of a leading train. (Note this condition 
is stated in terms of physical reality, not in terms of the estimates and 
uncertainties available to the control system.) This cannot be directly 
measured and must therefore be bounded (e.g., the probability of a train 
being more than 6 sigma ahead of the nominal position is on the order of 
10 “ 9 .) 

■ A train operating a speed higher than either the allowable maximum on 
a track segment. (Again, this is stated in terms of physical speeds, not 
estimates from the train tracking system or readings from tachometers.) 
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■ A train operating at a speed higher than an externally commanded reduced 
speed. 

58 The actual contract has a few other conditions associated with other elements 
of the system (e.g. problems with the locating and tracking system). Also, in 
the actual BART contract, this MTBH is limited to hardware faults. For this 
case study, we invite comment on how such a goal might be demonstrated for 
the design and implementation of the control algorithms. 

59 The Mean Time Between System Shut Down should be more than 26,000 hours 
system-wide. A “system shutdown” is any hardware failure or software fault 
that prevents the AATC from sending a speed command to the train control 
system on one or more operational control cars for a period of 5 seconds or 
more. 

60 The Mean Time Between Failure for a control station AATC must be more 
than 2,000 hours. A “failure” is any event that impairs subsystem performance 
or requires manual intervention. This is primarily being used to provide a 
performance metric for hardware failures, including ones that involve no loss 
of functionality due to redundancy, that require repair. 

61 The Service Reliability Requirement states that system wide all first failures arc 
to be repaired within 24 hours. Total service recovery time, which includes 
the time for maintenance crews to reach the equipment plus the mean-time-to- 
restore-service, shall average 12 hours. 

62 The Cold Start Boot-Up Time for a control station AATC, as would be required 
after a system shutdown shall be no more than 7 minutes. 

10. Vital Station Computer (VSC) Issues 

63 As noted in the introduction, the vital station computer system provides for a 
high degree of internal checking that drives any computational error rates down 
to safety-acceptable levels. Moreover, elements of system design, implemen- 
tation, and testing assure acceptable robustness against operating system and 
compiler faults. For the purpose of this case study, assume this system per- 
forms as desired. This specially-designed system is, however, relatively slow. 
(In the actual application, this machine is programmed in a relatively restricted 
subset of C++. We will not apply any particular language limitations in this 
case study.) 

64 Note that if VSC does flag a non- vital speed as unsafe, the command is not sent. 
If no commands reach the train for 2 seconds, there is a time out. This does not 
count against the MTBF number, but if the outage continues for 5 seconds it 
counts against the MTBSSD number. If the algorithm does not flag a non- vital 
unsafe speed as unsafe, it is a safety failure and if the trains actually enter a 
worst-case stopping distance of each other or of a closed gate, it counts against 
the MTBH number. 
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65 You may assume the following. Safety critical tables of train parameters used 
by the train control algorithm arc always available, i.e., they arc stored with 
enough redundancy to meet all safety and reliability requirements. 

11. Miscellaneous Questions and Answers 

66 Q: Can a train go backwards? 

A: No. 

67 Q: Does the control algorithm need to consider the case of a runaway train? 

A: No. This is managed by the controls built into the train. 

68 Q: Is a specific track always “one-way”? 

A: Yes, for the purposes of this case study. In actual operations there arc 
special protocols (reduced speeds, special routing rules) for operating a train in 
the reverse direction on a specific track. 

69 Q: Does the speed and acceleration control system need to consider routing of 
trains? 

A: No. Routing is done by the interlocking system and other external systems. 

70 Q: Is it true that, in general, a train must begin deceleration more than one 
segment prior to a closed gate? 

A: Yes. The worst case is spectacular. On a continuous 4% downgrade, a train 
at 80 mph would take over 3 miles to stop. 

71 Q: Although a train can be in either a propulsion or a braking mode, can it also 
be in a neutral mode? 

A: No, neutral, or coasting, is done in propulsion mode (with acceleration = 0). 
When in braking, the brake rate is at least -0.45 mphps. 

72 Q: Are all trains the same length? 

A: No, but for the purposes of this study, you can assume so. Nominally, during 
rush hours, trains arc made up of 10 cars, giving the total length of 710 feet 
introduced earlier. At off-peak times, shorter trains arc used. And even at rush 
hours, some lines may have shorter trains. 

73 Q: Why arc gates closed/opened? 

A: Gates arc like stoplights on a highway and they serve a similar purpose. A 
stoplight prevents traffic from entering an intersection where the traffic is going 
in the other direction. The gates define who has the right of way coming up to a 
switch where two tracks join or diverge. A gate prevents a train from entering 
a switch when it is set for traffic in another direction. A gate (and a stoplight) 
can also control or limit flow. 
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Q: If a gate wants/needs to be closed and the position of a train prevents this, 
why is this acceptable? 

74 A: This gets at the logic of train routing, with is beyond the scope of this case 
study, but some background might be useful. Gates being opened and closed 
essentially define who has right of way when tracks come together. The situation 
where a gate wants/needs to be opened or closed occurs when different trains 
want/need the switches positioned differently. The interlocking system is set 
up so that “wants” can be handled as expeditiously as possible, but trains that 
do not have the right of way may have to wait. The speed selection system has 
to make sure that a train moves into a position where it “needs” to have a gate 
in front of it changed. The interlocking system has to make sure that it never 
changes a switch so that a train is put at risk. (If the right-of-way is going to be 
changed, it may be the case that all the gates arc closed - the stoplights arc red 
in all directions - as a train finishes passing through a switch.) 

75 What actually happens is that as a train approaches a gate that is not open 
(but before it has to slow down), a separate system sends a “request” to the 
interlocking system asking for changes in switches and gate positions (i.e., that 
ask for changes in who has the right-of-way). A request is checked against 
the positions of all other trains near the switch. Acting on a requested action 
may occur in stages. All gates approaching the switch in question may be 
closed while a train is crossing a switch or is too close to stop. No switches 
will be moved until all trains are clear of the area. And only after a switch 
is physically moved will the appropriate gates be opened. When a routing 
request is not granted, a train that does not have the right-of-way will have to 
either slow down or stop until the gate opens. It is a functionality issue, but 
not a safety issue, to make sure that train schedules do not lead to too many 
conflicting requests and that routing requests come in early enough that they 
can be granted without having the trains slow down excessively. 

76 Q: Why arc we worried about going faster than the maximum speed on a piece 
of track? 

A: The train may derail. 

77 Q: Why arc we worried about entering a closed gate? 

A: If the gate is in front of an incorrectly aligned switch, the train may derail. If 
the switch directs the train onto an inappropriate track, there may be collision. 

78 Q: Why can't the train accelerometers detect the component of train acceleration 
due to gravity? 

A: An accelerometer is, in gross simplification, a mass at the end of a spring. 
Acceleration is measured by how much the spring is compressed. When the 
motors accelerate the train, the only way the mass gets accelerated is for the 
spring to push on it, so the spring is compressed. When the gravity accelerates 
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the train, it also accelerates the mass on the spring. There is no difference in 
the forces applied at the two ends of the spring, so no change (no differential 
acceleration) is measured. 

11.1 Sample Track Layout Information 

The table below summarizes the type of information attached to tracks segments. 



Begin 

(feet) | 


Segment 

End 

(feet) | 


Length 

(feet) 


Comment 


Civil Speed 
(mph) 


Grade 


Exposure 


5940 


6640 


700 


Daly City Station Platform 


36 


-0.80% 


Open 


6640 


6741 


101 




36 


-0.80% 


Open 


6741 




Gate 








6741 | 7588 


847 


Switches to Crossover and Spur 


36 


-0.80% 


Open 


7588 




Gate 








7588 


8522 


934 




36 


-0.80% 


Open 


8522 


8722 


200 


Parabolic grade transition. Midpoint at 8622 


80 


transition 


Open 


8722 


9003 


281 




80 


2.75% 


Open 


9003 




Control Station Boundary 








9003 


9509 


506 




50 


2.75% 


Open 


9509 


11355 


1846 


Parabolic grade transition. Midpoint at 10428 


50 


transition 


Open 


11355 


11900 


545 




50 


-3.50% 


Open 


11900 




Gate 








11900 | 12369 


469 


Switches 


80 


-3.50% 


Open 


12369 




Gate 








12369 


12500 


131 


grade 


80 


-3.50% 


Open 


12500 


13100 


600 


grade transition with midpoint at 12800 


80 


transition 


Open 


13100 


13400 


300 




80 


-2.11% 


Open 


13400 


14190 


790 


Parabolic grade transition. Midpoint at 13950 


80 


transition 


Open 


14190 




Tunnel Portal 








14190 


14500 


310 


Parabolic grade transition (continued) 


70 


transition 


Tunnel 


14500 


14850 


350 




70 


-3.19% 


Tunnel 


14850 


15150 


300 


Parabolic grade transition. Midpoint at 15000 


70 


transition 


Tunnel 


15150 


15410 


260 




70 


-1.00% 


Tunnel 


15410 


16110 


700 


Balboa Park Station Platform 


36 


-1.00% 


Tunnel 


16110 


16140 


30 




36 


-1.00% 


Tunnel 


16140 


16500 


360 




50 


-1.00% 


Tunnel 


16500 


17000 


500 


Parabolic grade transition. Midpoint at 16750 


50 


transition 


Tunnel 


17000 


17025 


25 




50 


-2.11% 


Tunnel 


17025 




Tunnel Portal 








17025 


17250 


225 




50 


-2.11% 


Open 


17250 


18075 


825 


Parabolic grade transition. Midpoint at 17650 


50 


transition 


Open 


18075 


18218 


143 




50 


-3.89% 


Open 


18218 


19245 


1027 




70 


-3.89% 


Open 


19245 




Tunnel Portal 








19245 


19550 


305 




70 


-3.89% 


Tunnel 


19550 


20550 


1000 


Parabolic grade transition. Midpoint at 20110 


70 


transition 


Tunnel 


20550 


20795 


245 




70 


2.14% 


Tunnel 


20795 


21295 


500 


Parabolic grade transition. Midpoint at 21045 


70 


transition 


Tunnel 


21295 


21485 


190 




70 


0.30% 


Tunnel 


21485 


22185 


700 


Glen Park Station Platform 


36 


0.30% 


Tunnel 


22185 


22420 


235 




80 


0.30% 


Tunnel 


22420 


22780 


360 


Parabolic grade transition. Midpoint at 22600 


80 


transition 


Tunnel 


22780 


24950 


2170 




80 


-0.68% 


Tunnel 


24950 


25635 


685 


Parabolic grade transition. Midpoint at 25300 


80 


transition 


Tunnel 


25635 


28025 


2390 




80 


-3.12% 


Tunnel 


28025 


28115 


90 




80 


transition 


Tunnel 


28115 




Control Station Boundary 








28115 


28374 


259 


Parabolic grade transition. Midpoint in next segment 


80 


transition 


Tunnel 


28374 


29025 


651 


Parabolic grade transition. Midpoint at 28525 


63 


transition 


Tunnel 
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Begin 

(feet) 


Segment 

End 

(feet) 


Length 

(feet) 


Comment 


Civil Speed 
(mph) 


Grade 


Exposure 


29025 


29835 


810 




63 


0.55% 


Tunnel 


29835 


30065 


230 


Parabolic grade transition. Midpoint at 29950 


63 


transition 


Tunnel 


30065 


30080 


15 




63 


-0.30% 


Tunnel 


30080 




Gate 








30080 


32281 


2201 




63 


-0.30% 


Tunnel 


32281 


32981 


700 


24-th Street Mission Station Platform 


36 


-0.30% 


Tunnel 



80 Notes for the table: 

■ The area controlled by one station computer is from location 9003 to 
location 28115 (total of 19107 feet = 3.6 miles). 

■ Note one station computer actually will control an area spanning two 
train stations in this example. 

■ Low numbered locations are to the west; numbers increase to the east. 

■ Civil speeds represent maximum allowable speed. Actual speeds can be 
lower. 

■ On these grades, the current system operates trains at speeds much lower 
than the civil speeds. 

■ This is one of the most hilly sections of in the BART system - much of 
the track is on flat ground. 

■ Negative grades are down hill travelling west to east; postive grades arc 
up hill west to east. 

■ For grade transitions, the plans give a mid-point, where the grade is 
halfway between the two grades at the ends. These three points (location 
and grade) define a parabola. 
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Abstract 

Motivated by the design and development challenges of the BART case study, 
an approach for developing and analyzing a formal model for reactive systems is 
presented. The approach makes use of a domain specific language for specifying 
control algorithms able to satisfy competing properties such as safety and opti- 
mality. The domain language, called SPC, offers several key abstractions such 
as the state, the profile, and the constraint to facilitate problem specification. 
Using a high-level program transformation system such as HATS being devel- 
oped at the University of Nebraska at Omaha, specifications in this modelling 
language can be transformed to ML code. The resulting executable specification 
can be further refined by applying generic transformations to the abstractions 
provided by the domain language. Problem dependent transformations utilizing 
the domain specific knowledge and properties may also be applied. The result is 
a significantly more efficient implementation which can be used for simulation 
and gaining deeper insight into design decisions and various control policies. 
The correctness of transformations can be established using a rewrite-rule based 
induction theorem prover Rewrite Rule Laboratory developed at the University 
of New Mexico. 



1. Introduction 

Motivated by the BART case study, an approach for developing and analyzing 
a formal model for reactive systems such as train systems is presented. The 
methodology presented is suitable for the development of control functions 
belonging to the class of reactive systems where the ability to predict behavior 
and deal with behavioral uncertainty is the dominating concern. The BART 
case study is used for illustrating the approach; the reader may also consult 
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[WKB01] for more details about how the proposed approach has been applied 
to the BART case study. 

Typically, the very first step in domain modelling is the identification of ab- 
stractions (both data and algorithmic) relevant to the formulation of a given 
problem or class of problems. There arc several well-known techniques that 
can be used for an analysis leading to the discovery of suitable abstractions. 
For example, Chapter 4 discusses a general purpose analysis method based on 
the identification of noun and verb phrases in the English description of a prob- 
lem. The focus of this chapter is not on techniques for identifying abstractions 
but rather on how a given set of abstractions can be utilized within a software 
development methodology that combines formal techniques, such as program 
transformation and verification, with validation techniques such as simulation 
and animation. 

1.1 Some Abstractions for Reactive Systems 

In the domain of reactive systems, the state and the transition arc examples of 
two widely-known abstractions. It is well understood that a formal model of 
any reactive system must include a description of the system's state. In this 
setting, a transition is an algorithmic abstraction capable of taking the system 
from one state to another. System behavior is achieved through a sequence of 
transitions. Requirements (e.g., safety requirements, throughput optimization) 
arc generally stated in terms of properties defined on states or state sequences. 
In a reactive system with an active controller influencing its behavior, as is the 
case here for train systems, considerable choices exist how the system evolves 
from a given current state. Instead of an explicit finite state transition table, 
there arc constraints on state trajectories capturing safety properties, e.g., for a 
train system, acceleration and speed of a given train should be so chosen as to 
avoid collision with the lead train, stop at red traffic lights, and obey the track 
speed limits. Only those transitions that keep the system system within a safe 
region of states arc thus allowed. Such high-level abstractions appeal - essential 
to specifying the behavior of a reactive system. 

1.2 Proposed Tools and Methodology 

The domain modelling language presented introduces a profile as the abstrac- 
tion for modelling state trajectories, and the constraint as the abstraction for 
modelling properties (e.g., safety properties). Relational expressions can be 
constructed from profiles and constraints describing transition sets whose el- 
ements ah satisfy the property specified by the constraint. Such expressions 
can be composed with one another using logical connectives and describe tran- 
sition sets whose elements satisfy the resulting formula (e.g., transitions that 
simultaneously satisfy multiple safety properties). From this set of transitions a 
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selection can then be made according to secondary criteria such as throughput 
optimization or passenger comfort. 

The domain modelling language introduced is used to define 

■ states (without taking into consideration any safety requirements), 

■ safe states, 

■ next state function that ensures that the system is always in a safe state, 

■ safety policy, and finally 

■ a family of controller functions. 

The proposed approach is able to select among a family of controller functions, 
different control policies optimizing different requirements. 

Using a high-level program transformation system such as HATS [Win99] being 
developed at the University of Nebraska at Omaha, descriptions (i.e., specifica- 
tions) in such a modelling language can be transformed to ML code. Optimiza- 
tion of this implementation is possible through generic transformations of the 
data structures and control structures supported in the domain modelling lan- 
guage. Further optimization can be obtained though the application of problem 
dependent transformations. A transformation is considered problem dependent 
if it correctness is based on domain/problem specific knowledge and proper- 
ties. The application of optimizations result in a significantly more efficient 
implementation. The control function, in its un-optimized or optimized form, 
can be plugged into a simulator in order to gain a deeper understanding of the 
consequences of various design decisions and control policies. The correctness 
of transformations can be established using an rewrite-rule based induction the- 
orem prover Rewrite Rule Laboratory [KW01] developed at the University of 
New Mexico. The BART case study is used to illustrate how the methodology 
can be used in practice. 

A key advantage of the proposed approach is the use of simulation and animation 
to debug and validate the formal model. An efficient implementation obtained 
from a high-level specification using a series of domain independent and domain 
specific transformations can be used for simulating a model. The model can 
be studied concretely, providing insight into its behavior and thus enhancing 
confidence in its correctness. The simulation can be linked to an animator to 
view different scenarios. Any problem identified or any anomalies can be traced 
back to the model and fixed in the model. After extensive simulation, when 
the designer and user feel confident about the correctness of the model based 
on extensive simulation scenarios, the model can then be subjected to rigorous 
formal methods in order to formally verify that desired properties properties 
arc preserved under the stated assumptions. 
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2. Technical approach and method 

The key steps of the proposed approach arc: 

■ using state and profile abstractions to model various aspects of the system, 

■ using constraints to model individual safety properties to the extent pos- 
sible, 

■ the definition of what it means to be a safe state with respect to a given 
safety policy, 

■ the definition of a family of controller functions and of an optimal control 
policy in the domain modelling language, 

■ application of transformations (both domain independent as well as do- 
main specific) on the definitions to obtain an efficient implementation, 

■ validation through simulation and animation of the above model on ran- 
domly generated scenarios and the animation of the resulting behavior; 
revising the above steps to debug the formal model and to ensure correct- 
ness, and 

■ verification (of the model as well as transformations used for the model). 

2.1 Reactive Systems: The Basics 

A reactive system is typically designed to achieve a desired objective while 
interacting with its environment. Actuators which arc under the control of the 
system as well as the state of the environment cause the system to evolve over 
time. The current state of the system (and the environment) is captured in terms 
of certain measurements obtained using a collection of sensors. Among various 
possible actions, certain actions arc chosen by the controller to ensure that the 
system state never violates any safety policy by entering into a state deemed 
unsafe. Typically, there is some flexibility in choosing among possible actions. 
As a result, other considerations can be taken into account for selecting the best 
possible action in every state. 

A reactive system is typically controlled incrementally by placing a control 
function core within a sense/react loop. In such a paradigm, each iteration of 
the loop corresponds to an incremental (discrete) control step. The duration 
for which a reactive system can run unsupervised is generally dependent upon 
three things: (1) the ability of the sensors to sufficiently capture the state of 
the system, (2) the fidelity of the system model used by the core, and (3) the 
ability of actuator commands to realize the desired system behavior. In this 
chapter, we will use the term uncertainty to broadly describe, in temporal terms, 
the shortcomings present in sensors, system models, and actuator commands. 
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Thus as the uncertainty of a reactive system increases, the frequency of the 
sense/react loops responsible for controlling the system must correspondingly 
increase (i.e., the system must be controlled at more frequent intervals). In this 
framework, a desired system behavior can only be assured when the period of 
the sense/react loop reduces the uncertainty in the system so that it falls within 
acceptable limits. The tolerances of models and capabilities of actuators define 
these limits. 

The sensors and actuators in a reactive system can be modelled, respectively, by 
a vector of monitored variables m = (m \ . m 2 , .... m n ) and controlled variables 

def 

c = (ci, C 2 , ..., Ck). For a more detailed treatment, see Janicki et al [JPZ96]. 
We extend the vector m with additional variables describing the information 

obtained from the trace history of the system. We denote the resulting vector M. ■ 

We say that Jv[ describes the monitored state of the system. The combination of 
M. and c describes the observable state of the system. LetM and C, respectively, 
denote the sets of all possible configurations of the extended monitored and 
controlled variables that arc allowed by the environmental constraints. The set 

S = { ( M. , c) \ M. GMAcGC} then describes the observable state space of 
the system. Given such a definition of a state, a system model can be constructed 
by defining the effect of a control value on any observable system state (i.e., 
how a control value can cause the system to transition from one state to the 
next). 

2.2 A Domain Modelling Language 

Our development makes use of a domain specific modelling language called 
SPC, an acronym standing for state, profile, and constraint. SPC is not a full- 
blown specification language; instead it simply provides primitives in a func- 
tional and relational framework enabling control function developers to con- 
struct abstractions suited for concisely modelling reactive systems and formally 
specifying their control functions. SPC encourages a relational perspective of 
computation[BKe97]. For example, rather than returning a single control vec- 
tor as the result of its computation, a relational control function might return 
the set of all control vectors satisfying the specification (e.g., all acceleration 
values for a train that enable it to meet the safety properties specified). The 
resulting control vector set is then passed to a filter function which selects an 
appropriate vector according to some other competing criteria (e.g., the maxi- 
mum acceleration, a train acceleration which best maintains passenger comfort, 
etc.). When considered in the context of the BART case study, a relational de- 
sign allows a clean separation of safety related constraints from non-safety 
related constraints. The decoupling of these constraints enables separation of 
concerns allowing the specification of train behavior to be decomposed into two 
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smaller/simpler specifications, and whose composition can easily be shown to 
satisfy safety properties. 

Another goal behind the development of SPC was to construct a framework 
in which formal specifications could be automatically manipulated in problem 
specific ways. Problem specific manipulation prohibits the application of rigid 
compiler techniques to carry out the translation from specification to imple- 
mentation. On the other hand, problem specific manipulation can be readily 
performed by a program transformation system. 

From the perspective of modelling and specification, SPC can be seen as a small 
programming language whose syntax and semantics has a functional flavor 
with mathematical overtones. From the perspective of implementation, SPC 
can be seen as a wide-spectrum language with strong emphasis on referential 
transparency. A BNF grammar for the entire wide-spectrum language SCP can 
be found in Appendix ??. 

An SPC specification is typically a set of definitions where each definition has 
one of the following forms: 

define data_abstraction = expression 

define data_abstraction = expression where definition-list 

In the second form, the keyword where has the same semantics as it does in 
standard mathematics. The left-hand side of the equality in a definition can 
be a variable or it may be a tuple. The expression on the right side of the 
equality operator can be a number of things including an anonymous function, 
a constant, a variable, or a data_abstraction. 

A control function in a reactive system might have the following form: 

1 input: The state of the system 

2 compute: The set of all actuator vectors AS that satisfy a given set of 
primary constraints. 

3 select: A vector v G AS according to a given set of secondary constraints. 

4 output: The vector v 

The above takes a system state as its input and returns an actuator value that has 
been selected from a set of actuator values satisfying the given constraints. At 
the specification level, a key difficulty is the definition of the system constraints. 
How constraints arc specified is heavily effected by the system model. As a 
result, their correctness is also dependent upon the correctness of the model. 

The State, the Next State Function, and the Profile. A state is simply a 
tuple of variables where each variable is quantified over a corresponding range 
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of sensor values, trace information, or actuator values. This aggregation of 
information constitutes the observable state of the system. 

state = (xi G £>i,X2 £ D 2 , ,..,x m € D m ) (2.1) 

where D, = a range of sensor values, a range of trace information values, or a 
range of actuator values. 

The next-state function calculates the next state of the system. More specif- 
ically, the calculation predicts the next state of the system. In contrast, the 
sense/react period precisely defines at which times, the control of the system 
is possible/allowed. Because of this limitation on control, it is not particularly 
useful to construct a system model in which the next-state function predicts 
behavior that requires “corrective” actuator values to be output at times that arc 
inconsistent with (i.e., do not align with) the sense/react cycle. Thus to limit 
the complexity of the controller, the next-state function and the sense/react loop 
should have temporal units that arc compatible. 

A profile is a finite sequence of states that either can be constructed explicitly 
or iteratively via the next state function. It is specified using an ML-like list 
notation: 



profile = [si,...,s k \ (2.2) 

An important yet subtle aspect of profiles is their indexing mechanism can be 
overloaded with respect to time. Specifically, models can be constructed in 
which profiles arc accessed by indexes that correspond to discrete clock ticks 
as defined by a universal clock. In the BART case study, this temporal indexing 
allows the position of two trains to be compared in a meaningful way - It is not 
as important to know where a train is as it is to know when it is there (e.g., two 
trains can only collide if they arc in the same position at the same time). 

A profile can be iteratively defined by passing a triple of the form: state 
x next-state x pred to an SPC function called list_inu. The evaluation of 
list_mu(s,f , Q ) results in a profile, whose initial state is s, and whose succes- 
sive states arc obtained by the repeated application of the next-state function/ to 
the state s. The final state in the profile is reached when the repeated application 
off to s yields a state s n for Q(s n ) holds. More formally we have, 

list_mu{s,f,Q) = \f°{s),...,f n (s)} (2.3) 

where f°(s) = 5 Af ,+1 (s) = f(f'(s)) A Vi : 0 < i < n — > -1 Q(f’(s)) A 

Q(f n (s)). 

In the BART case study, various stopping behaviors that a train might have (e.g., 
emergency stop or normal stop) arc computed using this construct. 

See the Appendix ?? for the operational semantics of list_nm. 
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Stopping Profile 




Figure 2.1. A stopping profile for a train 



Constraints. A constraint is an expression comparing two profiles. If the 
expression evaluates to true, the constraint is satisfied, otherwise the constraint 
is not satisfied. A special-purpose operator, <C, is used to compare profiles. A 
fully general parameterization of this operator is still under development. At 
present, two useful instances of <C have been identified. The first instance, 
which will be denoted <Ct can be used to compare profiles sharing a common 
time frame (e.g., two train profiles). The second instance, which will be denoted 
<Cs can be used to compare profiles in a temporally independent fashion (e.g., 
a train profile and a track profile). 

(Temporally) Dependent Constraint 

def 

tPot <T tpit = 

Mt £ int(size(tp ot )) : p\ < p 2 where (pi,Ji, ai) = tp 0 t[t\/\(p2,S2,a 2 ) = tpu[t] 

In the definition given, tp ot and tp/, denote (train) profiles whose states share a 
common time frame. The expression int(siz.e{tp ot )) calculates the cardinality 
n of the profile tp ot and creates the set {1, 2, ..., n) over which the variable t is 
then universally quantified. 

Let r denote a profile, i an index, and r(i) the i th element in r. Given this 
notation, the semantics of profile access by [ ] can be defined as follows: 

r[t] = | 

In the definition of tp ot <Ct l Pn- the expression tp ot [t] simply denotes the 
t ,h element of tp ot . Since size(tp ot ) need not be equal to size(tpi t ), potential 
problems exist only when using t to access elements of tpg. The definition of [ 



r(t) 


when size(r) > t 


f-(max_index) 


when size(r) < t and max_index = size{r) 
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] allows for a meaningful comparison between elements in tp ot [t] and elements 
in tpu[t] even in cases where size(tpi t ) < size(tp ot ). Similar examples of such 
normalizing extensions can be found in SequenceL [CK99]. 

The intuition behind the extension is that the temporally dependent profiles 
considered arc generated using a next function and have a last state satisfying 
a particular predicate (e.g., the train is stopped). Such a “satisfying” state may 
be (temporally) repeated without changing the semantics of the profile since in 
some sense this comparison is beyond our time frame. 

The key characteristic of a dependent constraint is that multiple profiles (e.g., 
tp ot and tpit) arc accessed by a single shared variable (e.g., t) denoting a common 
time frame. 

(Temporally) Independent Constraint 

def 

tpot <5 pf - QoifPouPf) A Q\(tp ot ,pf ) A Q 2 (tp ot ,pf ) 

where 

Qo(tpot,pf) = 

Mt G hit (size (tp ot ))Mj G int(size(pf )) : (pi = p 3 ) — >■ (si < s 3 ) 
where (pi,si,ai) = tp ot [t\ and (p 3 ,s 3 ) = pf\j ] 

Qi(tPot,pf ) = 

Mt G int(size(tp ot ) — 1) V/ G int(size(pf )) : (p\ < p 3 < p 2 )) — (max(si, j 2 ) 

< s 3 ) 

where (pi,si,ai) = tp ot [t\ and ( p 2 ,s 2 ,a 2 ) = tp ot [t + 1] and (p 3 ,s 3 ) = pf\j] 
Q 2 {tPof,P.f) = 

Mt G int(size(tp ot ) — l)Mj G int(size(pf) — 1) : (p 3 <Pi < Pi)) — >max(si, j 2 ) 

< S 3 

where (pi,si,ai) = tp ot [t\ and ( p 2 ,s 2 ,a 2 ) = tp ot [t + 1] and (p 3 ,s 3 ) = pf\j] 
and (p 4 :S 4 ) =pf\j + 1] 

The key characteristic of an independent constraint is that each profile is ac- 
cessed by its own private variable. 

We will use the temporally independent constraint operator <Cs to (1) compare 
train profiles with track speed limits, and (2) compare train profiles with track 
signals. All profiles can be modelled discretely in a piecewise linear - fashion. 
If one “connects the dots” in the graph of such a function what you end up 
with is a staircase-like relation. The construct <Cs says that when comparing 
two staircases, we do not want their lines to cross. In the context of our train 
system model, such intersections (i.e., line crossings) correspond to constraint 
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violations (e.g., the train exceeds the speed limit of the track segment on which 
it is travelling, or an object train collides with the train in front of it). 

Two staircases can intersect in one of three possible ways: (1) an intersection can 
occur at a staircase corner, (2) a vertical edge in the first staircase can intersect 
with a horizontal edge in the second staircase, and (3) a horizontal edge in the 
first staircase can intersect with a vertical edge in the second staircase. In the 
formal definition above the predicates Qq, Qi, and Q± respectively account for 
each of these cases. 

Multiple Constraints. Constraints are boolean expression that may be 
combined with one another using boolean operations. For example, if Ci and 
C2 denote two constraints then the conjunction Ci A C2 describes a boolean 
formula that can only be satisfied for values that simultaneously satisfy both Ci 
and C 2 . In the context of train system, a safety policy can be easily constructed 
given a complete collection of individual safety requirements. 

Filters. A relational paradigm provides a framework facilitating the com- 
position of safety requirements with non-safety requirements. The basic idea 
is to define a computation that produces the set AS of all actuator vectors satis- 
fying the safety policy of the system. This set can now be given as input to a 
secondary function F whose goal it is to select a value (i.e., an actuator vector) 
from ,4 .S' satisfying a given set of non-safety related constraints. Since every 
element in AS is safe, it really doesn’t matter (from the perspective of safety) 
which element of AS is selected by F. 

Given a set S and a constrain expression C, we will write [S : C] to denote a 
computation that selects the largest subset of S such that each element in the 
subset satisfies the constraint C. This operation is typically known as a filter 
operation on sets and its operational semantics is given in Appendix (section 7). 

Revisiting a Control function. The reader would notice that from the 
perspective of safety, each of the constructs needed to define a control function 
is now in place. For a specific reactive system, it becomes necessary to define 
states, constraints, and the next state function. Bear in mind that a typical reac- 
tive system it may be possible to transition to several states at any given time. 
The reason a particular transition is possible can be traced back to one of two 
root causes. First, a transition may reflect a particular - actuator value that can 
be selected by the control function. Second, a transition may be due to envi- 
ronmental conditions beyond the control of the system (e.g., the environment 
may cause a train to derail). 

define control function core = 



( fn system_state => 
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select ( [ actuator_values : constraints ] ) 

where ( 

define constraints = ... 
define select = ... 

) 

) 



In the controller framework shown above, the expression “(fn system_state 
=> ...)” is essentially the notation that ML uses to describe anonymous func- 
tions. For those unfamiliar with ML, a lambda calculus equivalent would be (A 
system_state. ...). 

2.3 Executable Specification through Transformations 

After a system model has been developed and a control function specified, 
it is transformed into an executable specification (program). Such programs 
should not be expected to be very efficient since they arc the product of a direct 
translation from a specification whose primary design goal was clarity (not 
efficiency). For efficiency reasons, it is therefore necessary to restructure a 
specification during the course of its translation into a program. Furthermore, 
in a typical development cycle program execution may produce insights that 
arc fed back to the specification, requiring revision of the specification and the 
(re)generation of another program. Because of such development cycles, it is 
desirable to automate the program generation phase to as large an extent as 
possible. Many factors must be considered when determining how to automate 
and what to automate in the program generation phase. 

When developing software for high consequence systems (such as the BART 
system), the ability to provide a convincing argument that the software has been 
built correctly is of utmost importance. Generally, such an argument is broken 
down into two smaller arguments. The focus of the first argument is to provide 
convincing evidence that the software system has been specified correctly. The 
goal of the second argument is to provide convincing evidence that the softw are 
implemented satisfies this specification. If both arguments can be made, then 
the software system is certified to be correct. 

Methods for providing evidence that an implementation satisfies a specification 
have been broadly classified as belonging either to Validation or Verification. 
Validation methods generally provide probabilistic evidence of a system's cor- 
rectness, which is often described in terms of reliability. For example, one 
can validate that a system responds correctly to an input test set. In contrast, 
verification methods make statements covering the entire input space. So the 
verification that a system's behavior possesses a property, V, can in some sense 
be seen as corresponding to exhaustive testing of the systems input space. 
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As the input space of a system increases, validation methods arc faced with 
significant problems. These problems arc compounded when the level of prob- 
abilistic evidence, that a system operates correctly, approaches 1.0 (i.e., the 
likelihood of a failure approaches 0.0). 

High consequence systems generally require strong evidence of correctness. 
For example, it it not uncommon for a high consequence system to have a 
requirement that the likelihood of failure in any given operational hour should 
be less than 1 in 10 9 . A system with a low failure rate requirement together with 
a sufficiently large input space will be resistant to validation-based approaches 
as the means for providing sufficient evidence of correctness. 

Additionally, over the years convincing arguments have been made that, in the 
high consequence realm, one generally cannot provide sufficient evidence about 
the intrinsic behavior of a system and instead must therefore rely on providing 
convincing evidence based on an analysis of a model of the system [BF93] 
[Hol97][Rus95]. Furthermore, it is also widely accepted that testing (model- 
based or otherwise) alone will not be sufficient to provide the level of assurance 
required. Thus, other analysis techniques, such as formal verification, must be 
brought to bear in order to provide a sufficient level of assurance that the system 
will not experience a failure. 

Transformation. A syntax-based (program) transformation system can be 
viewed as a rewrite system with refinement [Mor90][PS83], denoted by C, as 
the rewrite relation. The expression s C t asserts that .s' is refined by t, or t is 
correct with respect to s. In an automated transformation framework, deriving 
an implementation, S n , from a specification, So, proceeds in five steps: 

1 An initial refinement relation, — >c, is defined that is based on general 
refinement knowledge combined with basic (fundamental) problem do- 
main knowledge. Generally, — can be (re)used as the initial relation 
for all problems belonging to the problem domain. 

2 A domain theory, 'D, is constructed reflecting specialized domain knowl- 
edge and problem specific knowledge such as optimizations. 

3 Using the knowledge from 1 and 2, a problem specific refinement relation 
, — is designed. 

4 This relation, — >■%, is then realized in the form of a transformation func- 
tion, T. 

5 T is applied to So yielding S n as its result. The program S n is the “most 
refined” object that can be obtained from *So using — >-/j. 

In this approach, if all of the transformations in have been proved to be 
correctness preserving (i.e., they really are refinements) then, by the transitivity 
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of C, it follows that So C S„. Under the assumption that the transformation 
system executes T correctly, simply proving the correctness of the individual 
transformations in T is sufficient. However, if this assumption is not made (e.g., 
one assumes the tool may have bugs), then a correctness proof would also need 
to include a trace of the intermediate forms produced during the application of 
T to So, as well as a correspondence between intermediate forms, and 
which transformation, in T, was applied to what subterm in 5, in order to obtain 

Si+ 1- 

It should be noted that initially, considerable effort may be required to construct 
— From an economic standpoint, this approach to software development 
becomes attractive when a refinement theory, V, is defined for a problem domain 
for which many problems need to be solved. If this is the case, much of — can 
be reused and the cost of its development can be amortized over the problem 
space. 

HATS. The High Assurance Transformation System (HATS), as presented 
in [Win99], is a language-independent program transformation system whose 
development began in the late 1990s at Sandia National Laboratories and con- 
tinues at the University of Nebraska at Omaha as well as the University of 
Texas at El Paso. The goal of HATS is to provide a transformation-oriented 
programming environment, facilitating the development of transformation rules 
and strategies whose correctness can be formally verified. 

In HATS, programs belonging to a particular problem domain arc defined by a 
context-free grammar. Internally, HATS stores and manipulates these programs 
as syntax derivation trees. HATS provides a special purpose language for defin- 
ing transformation rules and strategies. This language enables the description 
of the domain language as a context-free grammar. 

HATS is an integrated development environment (IDE) for strategic program- 
ming [LVV03]. The HATS interface is written in Java and the execution engine 
is written in SML. The Java interface provides support for file management, 
editors for various tile types including text highlighting of keywords for the 
strategic programming language as well as term highlighting. The interface 
also provides control over execution of various portions of the execution engine 
(i.e., the parser, the interpreter, and the pretty printer), and supports graphical 
display of term structures. 

The HATS engine consists of three components: a parser, an interpreter, and a 
prettyprinter. A domain of discourse can be defined by a suitable grammar and 
lexer. The HATS parser supports an extended-BNF grammar and additionally 
supports precedence and associativity of operators and rules. The parser is an 
LR parser with the capability to do backtracking as needed in order to resolve 
local ambiguities. One can think of such a parser as an LR(K) parser for 
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an arbitrary K. Backtracking brings the parser’s capability close to that of a 
scannerless generalized LR parser [vdBSV98]. 

The programming paradigm supported by HATS is a strategic [LVV03]. A 
strategic framework can be thought of as a rewriting system where control of 
rule application and term traversal can be explicitly controlled by the user. A 
somewhat distinguishing feature of HATS is that terms correspond to parse trees 
rather than abstract syntax trees. There arc pros and cons to such an approach. 
However, one advantage of a parse-tree based perspective is that term structures 
can be completed by the parser (i.e., the developer need not explicitly write the 
internal nodes of a term). 

Strategic programs arc executed through an interpreter. HATS can be down- 
loaded from 

http://faculty.ist.unomaha.edu/winter/hats-uno/HATSWEB/index.html 

The HATS download is self installing runs on Windows NT/2000/XP and UNIX 

platforms. 

3. Inputs taken from the BART case study 

In this chapter, our goal is to formally develop a control function for a BART-like 
system. The focus of our effort is on the computer science side of the equation 
and not on the domain experts side of the equation. Ideally, we arc interested 
in developing a framework for constructing control functions that is to some 
extent parameterized on a function for predicting train behavior. For example, 
if a domain engineer develops a highly accurate function for predicting the next 
state of a train, then we would like to simply “swap out” our next-state function 
with this more accurate function leaving the rest of the controller unaffected. 
This goal provides the justification for disregarding certain aspects of the BART 
case study. In the following sections we describe the problem that we arc 
actually solving as well as the assumptions we arc making. 

3.1 Inputs Taken 

■ Trains within a track region arc controlled by a centrally located computer. 

■ Environment may introduce non-deterministic behaviors into the system 
in the form of derailments. 

■ A track region is cycle-free. 

■ A track region is uni-directional. 

■ Trains may not move backwards. 

■ The control function core will be embedded in a sense/react loop whose 
period is 0.5 seconds. 
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■ A track region may contain multiple trains. 

■ Trains may have different views of signal states (e.g., red vs green). 

■ Trains have two types of stopping modes, normal and emergency. 

■ A track segment is a fixed length of track whose position and speed arc 
also fixed. 

■ Track consists of a collection of track segments. 



3.2 Safety Policy 

■ Failures 

- Trains should not collide with one another. 

- Trains must stop at all signals (and stations) when required to do 
so. 



■ Hazards 

- An object train should not get so close to its lead train that it would 
be unable to stop should the lead train unexpectedly derail. 

- At no time should a train exceed the speed limit on the track segment 
on which it is travelling. 

- A train may only issue an emergency stop command when (1) the 
system is in an abnormal state, and (2) at no time upon entry of the 
system into the abnormal system state, was it possible for the train 
to stop using only a normal stopping profile. 

■ Other 

- In an abnormal state, a train should advance as far as possible. 



It is worth mentioning that the term track segment as it is used in the BART 
case study has a different semantics from how it is sometimes used in the 
context of other train systems. In other systems, “track segments” are paid of 
the interlocking system, and it is the interlocking system that is charged with 
enforcing many of the systems safety properties. For example, the interlocking 
system is oftentimes charged with the responsibility of preventing a train from 
entering a fixed “track segment” in situations where the segment is occupied 
by another train. In such a framework, the control function for a train need not 
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worry about getting too close to its lead train, as this aspect of the safety policy 
is entrusted to the interlocking system. The drawback of such a solution is that 
it may be far from optimal, since the “track segments” arc fixed regions on the 
track and the distance between trains is dynamically changing. 

In contrast, the control function presented does not rely on the interlocking 
system to assure such safety properties. The control function specified and 
implemented dynamically computes how close a train can be to a leading train 
while still preserving the properties set forth in the safety policy. Conceptually, 
one can think the control function as computing a dynamically changing virtual 
segment that exists between an object train and the lead train in front of it. 
This virtual segment then defines a hazardous region which if entered, would 
constitute a violation of the safety policy. 

3.3 Assumptions 

■ System 

- The system provides every object train access to the state of its lead 
train. 

- If a train derails, then the system is in an abnormal state, otherwise 
the system is in a normal state. 

- The positions of all trains arc known at all times, even in the case 
of a derailment in which case the derailed train is conservatively 
assumed to instantaneously come to a dead halt. 

- Acceleration commands arc given to trains in a synchronous fash- 
ion. The assumption that trains arc controlled in a synchronous 
fashion is central to correctness of the control function. Several 
safety properties arc specified in terms of temporally dependent 
constraints (discussed in Section ) involving the stopping profiles 
of an object train and its corresponding lead train. It is only through 
synchronous control that such constraints can be evaluated in a man- 
ner that is meaningful to physical reality. 

■ Environment 

- A derailment will cause a train to come to an instantaneous halt. 

- No assumptions arc made regarding when a derailment might occur. 

- No assumptions arc made regarding interlocking system's decision 
procedure for changing the state of a signal. 

- The interlocking system functions correctly and will only require a 
train to stop at a signal when, in fact, the train is able to do so. 
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- Our interpretation of the BART case study allows the interlocking 
control system to transmit different signal states to different trains. 
For example, if a train is too close to a signal to stop, the interlocking 
control system will tell the train that the signal is green. However, 
at the same time, if another train is able to stop for the signal, the 
interlocking system may tell this train that the signal is red (i.e., 
the gate is closed). This implies that each train will receive its own 
(possibly distinct) description of signal states. 

■ Train Behavior 

- An emergency stop is considerably quicker than normal stop. (See 
Appendix ?? for a discussion on this.) 

- The control function has access to auxiliary functions capable of 
generating both normal as well as an emergency stopping profiles. 
These functions make use of a next- state function whose period 
corresponds to the sense/react cycle of the system. 

- In any given state, there exists a (possibly empty) set of normal as 
well as emergency acceleration values that arc physically possible. 
In general, only a subset of the physically possible accelerations 
will satisfy the safety policy. 

- The control function, not the interlocking system, is responsible 
for: 

* ensuring that trains do not collide with one another 

* ensuring that trains do not get so close to one anther that haz- 
ardous conditions exist. 

Corollary 2.1 Train behaviors need only be compared in a pairwise fashion 
from the perspective of the safety policy as well as the optimization policy. 

Corollary 2.2 In order to satisfy the safety policy, a train does not need to 
know when the system is in an abnormal state. 



3.4 Abstractions and generalizations 

■ Train has no length. It is worth mentioning that only a minor extension 
to the model presented would be required to capture the length of a train. 

■ The state of a train at a given moment in time is modelled by a triple 
consisting of its position, speed, and acceleration. 
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■ Normal acceleration values arc modelled as a set of typed values. Normal 
= {flli «2, ••««} 

■ Emergency acceleration values are modelled as a singleton set of typed 
values. Emergency = {e} 

■ Access to the normal acceleration values is provided by the function: 
Af A : speed x acceleration — > set of acceleration values. Access to the 
emergency acceleration value is provided by the function £S A : unit — > 
e. 

■ Track segments can be modelled by a (position, speed, length) tuple. 

■ The track consists of a sequence of track segments. 

■ The set of physically possible train accelerations is a function of the 
train’s current speed and acceleration. 

■ The track is modelled as a profile of position-speed tuples, where each 
tuple describes a track segment. In order for a track profile to be well- 
formed, its track segments must be monotonically increasing on position. 
Consider two adjacent tuples (pi, s\)(p 2 , $ 2 ) belonging to a track profile. 
We use the term track segment to denote the region of the track that begins 
at pi and goes up to (but does not include) P 2 . All positions on the track 
belonging to the track segment beginning at p\ have a speed limit of .sq. 
For the sake of completeness, the track model requires that the final track 
segment in a profile have a speed limit of 0 mph. This final track segment 
serves as an end of track marker and when taken together with the track 
speed limit safety constraint will ensure that a train control function never 
try to drive a train past the end of the track. 

■ Signals are modelled in a fashion similar to track segments. In fact, one 
can think of a signal as defining a track speed limit, that varies over time 
for a particular' region of the track. When the signal is red the speed limit 
for the corresponding track region is 0 mph, and when the signal is green, 
the speed limit for the corresponding track region is unconstrained and 
can be modelled by the maximum speed limit for the track (e.g., 80 mph 
in the case of the BART case study). 

■ The system modelled consists of three components, a track, a collection 
of signals, and a collection of trains. 



4. Applying the approach to the case study 

In this section we describe how the approach described has been applied to the 
BART case study. A summary of the what was done follows: 
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1 Develop a model of the train system. This includes models of the track, 
signals, and trains. 

2 Using the model as a basis, formally specify a safety policy for trains. 
This policy will be expressed using constructs from the language SPC. 

3 Formally specify a train control function satisfying the stated safety pol- 
icy. 

4 Transform this specification into an executable specification. 

5 Embed the executable specification in a simulator and animate the result- 
ing system behavior. 

6 Apply optimizing transformation in order to obtain an efficient imple- 
mentation. 

4.1 Modeling the Track and Signals 

Table 2. 1 shows a fragment of the track layout table taken from the BART 
case study. Following this table is a profile describing the track and a profile 
describing the current state of the gate signals. Recall that the state of the gate 
signals is relative to a particular train. 

Notice that the track model and the signals model has the final segment (8722, 0) . 
As discussed earlier, such a segment should be added to the end of the track 
and signals for safety reasons. In this small example, the assumption is that the 
physical track ends at position 8722. 

Figure 2.2 shows graphical representation of the track model as seen from our 
simulator. The region below the track speed limit is considered safe with respect 
to the track speed limit safety property. Conversely, the region above the track 
speed limit is unsafe. 

4.2 Model of Train Behavior 

In Table 2.2, the next function defines how a train transitions from one state 
to another. Two acceleration functions, Acceli and Accel 2 are then defined 
that respectively select minimum normal and emergency accelerations values. 
The predicate Q defines what it means for a train to come to a halt, and the 
functions nStop, eStop, and dStop, respectively define a normal stopping profile, 
an emergency stopping profile, and the profile resulting from a derailment. 

4.3 Specification of Safety Policy 

From the perspective of the safety policy, the fundamental question that must 
be repeatedly asked of a train is: “How long will it take to stop or slow down in 
a particular state?” Given a train state and a model describing train behavior, 
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Segment Attributes 



Begin 

(feet) 


End 

(feet) 


Length 

(feet) 


Comment 


Speed 

(mph) 


Grade 


Exposure 


5940 


6640 


700 


Daly City Station Platform 


36 


-0.80% 


Open 


6640 


6741 


101 




36 


-0.80% 


Open 


6741 


Gate - displaying GREEN 








| 6741 


7588 


847 


Switches to Crossover & Spur 


36 


-0.80% 


Open 


| 7588 


Gate - displaying RED 








7588 


8522 


934 




36 


-0.80% 


Open 


8522 


8722 


200 


Parabolic grade transition 


80 


2.75% 


Open 



Track Model = [(5940, 36), (6640, 36), (6741, 36), (7588, 36), (8522, 80), (8722, 0)] 
Signals Model = [(6741, 80), (7588, 0)(8722, 0)] 

Table 2.1. An Actual Fragment of the BART Track and Corresponding Model 



next(f) ‘=fn (p , s, a) => (p + s + |a', s + a ' , a') where a 1 =f{p , s, a) 
Acceh =fn (p,s,a) => mm sel (Af ~A(s, a)) 

Acceh =fn (p,s,a) => £S_.4() 

Q((p, s, a)) = s = 0 A a = 0 

dcf 

nStop(state) = list-inu(state, next (Acceh), Q) 

dcf 

eStop(state) = list_mu(state,next(Accel 2 ),Q ) 

clStop((p,s,a )) = [0, 0, 0)] 



Table 2.2. Modeling the Train Behavior 
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Figure 2.2. Display of Track Model 



it is possible to answer this type of question by calculating a stopping profile. 
A stopping profile consists of a sequence of train states in which the final state 
is of the form (/;. 0, 0). That is, a behavior that results in the train coming to a 
halt. Additionally, we require that a stopping profile be minimal in the sense 
that, for a given state, it is not possible to select alternate acceleration values 
that would cause the train to stop (or slow down) in a shorter distance. 

Given this definition of a stopping profile, the strategy for the control function 
can be simply stated: 



Continue accelerating the train so long as the stopping profiles satisfy the corre- 
sponding safety constraints 



Clearly, as long as this property holds the train’s behavior will be safe. The 
question that arises at this time is: “What does it mean for a train to satisfy the 
constraints set forth in the safety policy?” 

Analysis of the safety property that the object train under consideration should 
not collide with its lead train (i.e., the train immediately in front of it) concludes 
that the stopping profiles of trains may be compared locally in a pairwise fashion. 
In particular - , global state need not be considered when determining whether this 
safety property holds. Global considerations are generally not useful due to the 
fact that limited assumptions can be made regarding the future behavior of any 
train (e.g., the environment can cause a train to derail at any moment). 
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For example, it is not unreasonable to assume that a train may slow down for a 
variety of unanticipated reasons. An example of this can be found in the BART 
system where a train will initiate an emergency stop if it fails to receive a valid 
command from the controller. Additionally, it may be prudent to allow a train 
operator to manually initiate a braking sequence (e.g. , if an automobile is stalled 
on the track, etc.). Due to this uncertainty, an object train must conservatively 
assume that at any given time step, its lead train will do one of three things: 
(1) initiate a normal stop, (2) initiate an emergency stop, or (3) derail. Failure 
to make such assumptions will open the door to worst case scenarios that the 
controller would not be able to safely handle. Thus, a conservative view of the 
kind described above does not benefit from additional information present in the 
global state. The reason being that the behavior of a lead train, when considered 
independently from the remaining trains in the system, is the limiting factor for 
every corresponding object train. 

Another aspect that should be considered is the length of the emergency stopping 
profile as compared to the length of the normal stopping profile. If an emergency 
stop takes longer than a normal stop, then arguably a situation would never arise 
where the emergency stop would be preferred over the normal stop. Thus no 
calculation would need to be made regarding which stopping behavior to use. 
However, if the distance of the emergency stop is smaller than the distance of 
the normal stop, then additional limiting factors must be considered such as 
when an emergency stop may be issued. Intuitively, it seems unreasonable to 
include the emergency stop as paid of the normal behavior of the system. 
Formally, we write 

object_train_profile < 7 - lead_train_profile (2.4) 

to denote that the given object train profile satisfies the constraints placed upon 
it by the given lead train profile. The <Ct operator denotes a position-time 
comparison and is defined in Section . 

To capture safety constraints with respect to the track and signals, we write 

object_train_profile <Cs track_or_signals (2.5) 

to denote that the given object train profile satisfies the constraints of the given 
track or signals profile. In this equation, the <Cs denotes a position-speed 
constraint and is defined in Section . 

Model of Safe State. The safety policy is defined in terms of a SafeState 
and SafeTransition predicate. The SafeState predicate can be used to determine 
if a given train, the object train , is presently in a safe state. The SafeState 
predicate holds for a given object train when ( 1 ) its normal stop profile satisfies 
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def 

SafeState(state 0 t, state,,, track, signals) = 

nStop(state ol ) track A 

nStop(state ol ) signals A 

nStop(state ol ) <^TCurrentStop(state„) A 
eStop(state ol ) <^TeStop(state„) A 
eStop(state ol ) <^TdStop(state„) 



Table 2.3. A Specification of Safe States 



the track speed limits, (2) its normal stop profile satisfies the states of the signals 
presented to it by the interlocking system, (3) its normal stop profile satisfies 
the current stopping profile of the train immediately in front of it (i.e., its lead 
train), (4) its emergency stop profile satisfies the emergency stop profile of its 
lead train, and (5) its emergency stop profile satisfies the derail stop profile of 
its lead train. 

Intuitively, if the normal stop profile of the object train satisfies the track profile, 
this means that normal acceleration values exist which the control function for 
the object train can use to assure that the speed limit of the track will not be 
violated. A similar explanation describes what it means for the object train to 
satisfy the signals profile. 

The third constraint in the SafeState predicate is the most interesting. It is this 
constraint that when taken together with the SafeTransition predicate assures 
that a train never needlessly issue an emergency stop command and that the 
train advance as far as possible in an abnormal environment. In a normal 
environment, the stop behavior for the lead train will be a normal stop. In an 
abnormal environment, the stopping behavior for the lead train may be either a 
normal stop, an emergency stop, or a derail stop. It is only when this constraint 
gets tripped that the object train will be permitted to issue an emergency stop. 
The fourth and fifth constraints state that the object train emergency stop profile 
should always satisfy the emergency stop and derail profiles of the lead train. 

Model of Safe Transition. The SafeTransition predicate defines the condi- 
tions under which an object train may transition to its next state. The parameter 
statelot denotes the current state of the object train, and the parameter state'!,,, 
denotes the state to which the object train may wish to transition. If state!,,, is a 
safe state, this means that the object train can satisfy all of the safety constraints 
without needlessly availing itself of its emergency stop capability. Thus there 
exists at least one transition out of statel ot satisfying this condition. Now the 
transition to state!,,, may or may not be such a transition. If it is, then it will 
also satisfy the SafeState predicate. 
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def 

SafeTransition(statel 0 t,state2 ol ,stateli,,track,signals) = 

SafeState(statel ol ,stateli,,track,signals) — > SafeState(state2 ol ,stateli,,track,signals) A 
-i SafeState(statel ol ,statelit,track,signaIs ) — > ( isSype(a ') = emergency stop) 
where state2 ol = (p',s',a ’) 



Table 2.4. A Specification of Safe Transitions 



ControU(state 0 i, stateu, track, signals) = select( [J\f-A(s,a) : Acc\ ) 

where ( 

(p, s, a) = state 0 t 

) 

select = if S = SET_EMPTY then SS^AQ else SETJVIAX(S) 

Acc = fn a'=> SafeTransition(state 0 i,next_accel(state 0 i),si,, track, signals) 

where ( 

nextsxccel = next (fn state => a') 

) 



Table 2.5. Specification of a Control Function 



On the other hand, if state l ot does not satisfy the SafeState predicate, then the 
transition to state 2 ot must be the result of an emergency stop acceleration. That 
is, in this situation the object train is forced to issue an emergency stop. 

4.4 Specification of Controller 

Give a train model and the definition of SafeState and SafeTransition, the spec- 
ification of the control function is quite simple. The control function calculates 
all of the normal stop acceleration values capable of satisfying the safety con- 
straints, and the select function then selects the maximum value from this set. 
However, if none of the normal accelerations are safe, the select function will 
select an emergency stop acceleration value. 

4.5 Transformation 

In this section, highlights are given of various transformation steps used to derive 
an ML program from the given specification. Transformation will be discussed 
at the conceptual level to the extent possible. That is, rather than inundate the 
reader with the syntactic details of a particular transformation system (such 
as HATS), transformational ideas arc discussed at the abstract level. Those 
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interested the details surrounding the implementation of such transformational 
ideas in HATS arc encouraged to read [Win99][WRW03]. 

Strategy for obtaining an executable specification: 

1 Unfold all definitions. 

2 Apply transformations that lower the level of abstraction of various do- 
main constructs. 

3 Apply transformations that replace primitive constructs and data with 
equivalent ML constructs and data. 

Unfolding Definitions in the Specification. Unfolding definitions within 
the specification, in effect, requires the interpretation of such definitions as 
transformations in their own right. This can present somewhat of a challenge 
for domain independent transformation systems as it is somewhat of a meta- 
operation. In HATS, this type of meta-operation is supported via a construct 
known as a dynamic transformation. Dynamic transformations arc transfor- 
mations with free variables that can be instantiated with respect to a specific 
problem instance. The most common use of type of transformation is for vari- 
able renaming. However, the context of the train control problem it is used to 
perform macro-unfolding. For a more detailed discussion of dynamic transfor- 
mations see Winter et al [WRW03]. 

Lowering the Level of Abstraction. Transformation 1 takes advantage of 
the fact that all sets in SPC arc finite. This transformation will express a uni- 
versally quantified formula in terms of a filter function. Recall that constraints 
were defined in terms of universally quantified first-order formulas. 

Transformation 1: 

fix G S : P(x ) ==> [S :P]=S 

Note that for finite sets, an expression such as [5 : P] = S can be effectively 
computed. 

Transformations 2 through 5 build upon one another for the purpose of achiev- 
ing a specific objective. Their combined application places any program they 
arc applied to (e.g., the control function specification) into a normal form. In 
the transformation community, normal form and canonical form arc terms fre- 
quently used when referring to intermediate stages in a transformation sequence 
that establish interesting properties. In the case of transformations 2 through 5, 
the interesting property established is that the profile accessing construct [ ] de- 
fined in Section has been removed from all filter expressions. Note that the 
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transformations shown assume that a single profile is being accessed. In such 
cases, the normalization problems discussed in Section arc not encountered. 
Transformation 2 simultaneously factors the int and size functions out of filter 
expressions. This transformation is used to change from a data representation 
where elements of profiles are accessed by indexes to a representation where 
element access will ultimately be realized by the list accessor function first. For 
example, S[l] =first(S). 

Transformation 2: 

[i int(size(S )) : ( fn t => F(S[f])] = int(size(S)) 

int(size([S : (fn x => F(*)])) = int(size(S )) when all occurrences of t in F 
arc in subexpressions of the form S[t] 

Here, size is a function that calculates the number of elements in a list and int is 
a function that converts an integer n into the list [1 , 2, 3, ...,«]. It is important to 
note, that Transformation 2 should be applied only when t is used as an index 
within F. In HATS, such checks can be described by boolean expressions that 
specify the application condition for a transformation. In general, a HATS 
transformation may only be applied when its application condition evaluates 
to true. For complex conditions of the kind required by Transformation 2, 
dynamic transformations have proven themselves to be quite useful. 
Transformation 3 is based on a simple observation that zip(S, tail(S)) produces 
a list of tuples whose size (i.e., length) is one less than the size of S. Here 
we assume the standard semantics for the functions zip and tail, namely, zip 
performs a pairwise composition of the elements of two lists, and tail removes 
the first element of a list. 

Transformation 3: 

int(size(S) — 1) ==> int (size (zip (S, tail (5)))) 

Transformation 4 is similar to Transformation 2. The difference is that Trans- 
formation 4 allows t to occur as an accessor to S in two different ways: .S' ft] 
and .S' ft + 1], This type of transformation is useful for lowering the level of 
abstraction for the temporally independent constraints discussed in Section 2.1. 

Transformation 4: 

[int (size (zip (S, tail (S)))) : (fit => F(5[t], S[t— 1])] = int(size(zip(S,tail(S )))) 

int (size ([ zip (S, tail (S)) : (fn (xl,x2) => F(vl,x2))])) when all occurrences 
of t and t — 1 in F are in subexpressions of the form S[t] and .S' ft — 1], 
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And finally. Transformation 5 simply removes any unnecessary int and size 
function applications. 

Transformation 5: 

int(size([S : F)) = int(size(S )) ==> [5 : F] = S 

Implement base functions and data in ML. The transformations in this 
phase are quite straightforward. A primary reason for this is the conceptual 
compatibility between SPC and ML. Examples of various syntactic driven trans- 
formations arc shown below. 

1 F — * G ==> if F then G else true 

2 F where definition-list ==> let definition Jist in F end 

3 and ==> andalso 

4 MIN ==> Real. min 

5 MAX ==> Real.max 

6 SET_EMPTY ==> nil 

7 SET_MAX( S ) ==> List.foldl Real.max Real.neglnf S 

8 -i ==> not 

9 [S :F\=S ==> List.all(ES) 

10 zip(Sl,S2) ==> ListPair.zipfS 1 ,S2) 

It should be noted that it is in this stage where the choice of the implementation 
language becomes fixed. For example, if a decision was made to transform 
the control function specification to C instead of ML, then the transformations 
in this stage would need to be changed and library functions supporting a list 
datatype (or something equivalent to it) would need to be developed. 

4.6 Simulation and Animation 

Additional Assumptions. 

■ There exist no speed or length dependencies between track segments. 
For example, it is realistic for a simulator to use a random function to 
generate the speed and length of track segments. 

■ Signal states may be randomly generated, provided that trains arc only 
asked to stop for a signal when they arc able to do so. 
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The Simulator. Initially, in order to validate the control function as well 
as try out different multi-train scenarios, a simulator was built. The simulator 
was written (by hand) in ML and models the track, the interlocking system, 
the environment, as well as unpredictability of the lead train. The simulator is 
initialized by: 

■ generating n track segments having a length and speed values that ran- 
domly fall between given parameters, 

■ composing the track segments to form a track, 

■ generating m signals spaced at random intervals on the track, 

■ selecting the number of trains to be controlled by the control function, 
and 

■ selecting various randomness parameters for influencing the behavior of 
the lead train of the system. 

The aggregation of these components forms the system state, which is given 
as input to the sense-react loop. The sense-react loop proceeds by calling the 
control function with the appropriate state information for each train. The lead 
train of the entire system is controlled by a special control function which differs 
from the developed control function two ways: 

1 Where the developed control function selects the maximum acceleration 
from the computed set of safe acceleration values, the system lead train 
pseudo-randomly selects an acceleration value from this set. 

2 The system lead train will occasionally derail thereby occasionally forc- 
ing the following trains to switch from a normal stopping mode to an 
emergency stopping mode. 

A parameter, k, is used to control the period in which signals can be changed. 
That is, every k sense-react cycles, the signal states arc randomly changed. And 
finally, after every sense-react cycle, various static properties of the resulting 
state arc checked by an oracle. The properties checked arc: 

1 Whether a train collision occurred. 

2 Whether a track speed-limit violation occurred. 

3 Whether a signal violation occurred. 

If a static property is violated, the oracle raises an exception and outputs an 
appropriate error message. On the other hand, states that satisfy the test oracle 
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train 1 


train2 


train3 


train4 


train5 


train6 


train7 


train8 


start 


0 20 


200 20 


400 20 


600 20 


800 20 


1000 20 


1200 20 


1400 20 


step 1 


23 26 


223 26 


423 26 


623 26 


823 26 


1023 26 


1223 26 


1423 26 


step 2 


52 32 


252 32 


452 32 


652 32 


852 32 


1052 32 


1252 32 


1452 32 


step 3 


86 36 


286 36 


486 36 


686 36 


886 36 


1086 36 


1286 36 


1486 36 


step 4 


122 37 


322 37 


522 37 


722 37 


922 37 


1122 37 


1322 37 


1522 37 



Table 2.6. A partial output of the simulator 



are appropriately filtered and output to a file in the form of a vector of numbers. 
Initially, the position and speed of every train was written to a file. The table 2.6 
is an example of the output of a 4 step (i.e., 2 second) simulator run for a system 
containing eight trains. 

It quickly became clear that such data files were not particularly enlightening. 
Therefore an effort was undertaken to construct a graphical display capable of 
animating the state changes that were being described in the data file. In addition 
to displaying the position and speed of every train, the track segment and signal 
states arc also displayed. This required a slight modification to the data file. 
The structure of the data file can be formally described by the following regular 
expression: 



track seg^ display position + (train 1 display state + ) + (2.6) 



where track seg = position speed, display position = number, train = position 
speed, and display _state = [0-2]. An example of how this information is dis- 
played is shown in Figure 2.3. The display is in color. Track segments shown 
in maroon with the starting position of each segment indicated by a rectangle. 
Trains arc displayed as blue triangles and arc connected by a blue line to en- 
hance the users ability to see (dis)continuities. The line connecting two trains 
is broken if the distance between two trains becomes so large that the line con- 
necting them does not help the user to process the visual information. Signals 
arc displayed as vertical bars and arc shown in three colors: green, yellow, and 
red. A signal whose state is displayed as yellow indicates that at least one train 
currently behind the signal sees the signal as being in a green state and that at 
least one train behind the signal simultaneously sees the signal as being in a 
red state. (Recall that the interlocking system can assign different signal states 
to different trains.) A signal whose state is displayed as red indicates that all 
trains behind the signal have a consistent view of the signal as being in a red 
state. Similarly, a signal whose state is displayed as green indicates that all 
trains have a consistent view of the signal as being in a a green state. 
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Figure 2.3. The Graphical Display - Trains stopping for a red signal 



4.7 Optimization 

Simulator runs using the executable specification raised concerns regarding 
the ability of the control function to satisfy real-time constraints. This led to 
an optimization cycle where transformations were developed that significantly 
reduced the computation sequences needed evaluate various expressions within 
the control function. Many opportunities for optimization were identified, with 
several of the more interesting optimizations presented below. 

Fusing properties and constraints. Within the context of the train control 
specification, safety properties are expressed as the conjunction of constraints. 
The unfolding of these constraints gives rise to a lengthy expression involv- 
ing a conjunction of first-order formulas. In this conjunction, each formula 
has its own quantified variables. Frequently variables in different formulas arc 
quantified over the same domain (i.e., profile). In these situations, the redun- 
dant generation of profiles can be avoided by the fusing formulas. Recall that 
stopping profiles arc generated by a computation involving list-mu. 

This form of fusing can occur between constraints as well as within a temporally 
independent constraint. For example, in Section <2o , Qi, and 02 all can be 
fused in the manner described here. In addition to the efficiency obtained by 
avoiding the regeneration of constraints, a savings is also obtained by avoiding 
the redundant examination of profile elements. 

Let PF denote a profile whose elements must be generated. 

The goal of this transformation is to avoid redundant generation of profiles 
as well as redundant examination of profile elements. Thus, if PF denotes an 
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expression that must be evaluated in order to produce a profile, then expressions 
such as 



(Vjc G PFV y G S : F) A (Vx G PFVy G S : G) (2.7) 

would require PF to be evaluated twice. Furthermore, the expression would 
require the elements in PF as well as S to accessed twice. Optimization 1 fuses 
two formulas sharing the same quantified variables. The resulting expression 
requires only a single generation of PF and S. In addition, further optimizations 
can be applied to short-circuit the evaluation in cases where values not satisfying 
PF or S are encountered. Optimization 2 fuses two formulas sharing a single 
quantified variable. 

Optimization 1: 

(Vx G PF Vy G 5 : F) A (Vx G PF Vy G 5 : G) 

(Vx G PF Vy G S : F A G) 

Optimization 2: 

(Vx G 51 Vy G 52 : F) A (Vx G 51 Vz G 53 : G) 

(Vx G 51 : (Vy G 52 : F) A (Vz G 53 : G)) 

Common subexpression elimination. Even after fusing optimizations 
have been applied, formulas can exist which require a profile to be regenerated 
multiple times. For example, a formula like: 

(Vx G expr l : (Vy G expr 2 : F)) (2.8) 

will require multiple regenerations of expr 2 in cases where expr 2 is denoted by a 
formula requiring generation, such as nStop (state ot ). Such regeneration can be 
avoided by binding the profile expression to a variable and then substituting this 
variable in place of the original profile expression. Optimization 3, introduces 
a let construct to achieve such a local binding, thereby moving the calculation 
of set ^expression outside of the V construct. 

Optimization 4 allows nested let expressions to be collapsed. The assumption 
here is that name conflicts do not arise, but such properties can be easily assured. 

Optimization 3: 

(V x G set -expression : F) 
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let 51 = set^expression in (Vx €51 : F) end 



Optimization 4: 



let 51 = expr 1 in (Vx € 51 : let 52 = expr 2 in (Vy € 52 : F) end) end 

let 51 = expr 1 52 = expr 2 in (V x € 51 : (Vy € 52 : F)) end 

Problem Specific Optimizations. All of the safety properties specified for 
the train control function arc monotonic with respect to acceleration. Infor- 
mally, one can argue that “slower is safer”. Formally, one can prove that forall 
acceleration values ct\ if an acceleration value a -2 satisfies a safety property P 
and if «i < 02 , then a \ will also satisfy P. This knowledge enables a descend- 
ing enumeration of the acceleration values to be short-circuited as soon as an 
acceleration value has been found satisfying the safety policy. 

5. Results raised by this technique 

There arc many insights gained by the proposed approach. The first and fore- 
most is that before any formal verification of properties of a complex reactive 
system can be undertaken, it is extremely useful to do simulation runs to gain 
confidence in the formal model, especially understanding how close it is to the 
real system being formalized. Animation techniques can be helpful in focusing 
on key aspects of the system behavior as well as comprehending large amounts 
of data. Often, it takes many iterations for a formal model to be debugged in 
order to be consistent with reality. It is essentially impossible to get it right in 
the first few attempts. Given that formal verification, which attempts to estab- 
lish that a given system is devoid of any bugs, is extremely expensive, it makes 
sense to use such techniques only when other techniques to debug the formal 
model have been exhausted. Otherwise, one could waste significant resources 
on identifying problems in a model which might have been detected easily using 
simpler and less expensive techniques. 

The success of the proposed approach is based on developing a formal model 
of a reactive system in a high-level language and then applying problem inde- 
pendent and domain specific transformations to obtain an efficient executable 
specification from the formal model. Using an executable specification, sim- 
ulation runs can be easily performed to analyze different scenarios. As the 
model is debugged, transformations arc repeatedly applied so as to generate an 
executable specification to run simulations. Any changes in the formal model 
can thus easily get reflected in the executable. High-level transformations play 
a crucial role in making this approach effective. 
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The effectiveness of the proposed approach relies on the ability to develop 
transformations which can be applied on high-level specifications of reactive 
systems to generate efficient executables. Further, the correctness of these trans- 
formations should be relatively easy to establish, preferably using automated 
techniques. Confidence in the correctness of the transformation process is es- 
sential, otherwise an executable specification may produce erroneous results 
even though the associated formal model is correct. 

6. Conclusion 

An approach for developing a formal model of a complex reactive system as 
a train system motivated by the BART case study is discussed. The approach 
relies on defining key abstractions in a reactive system, such as state, next 
state function, profile, in a high-level functional language; safety policies arc 
specified as constraints on profiles since other components such as signal, station 
and track can also be described as profiles. A control function can be described 
algorithmically, taking into consideration, specific physical characteristics of a 
train system. 

A specification is developed in a high-level functional language that supports 
the key abstractions of reactive systems. The specification is then transformed 
to an efficient executable using both problem independent as well as domain- 
dependent transformations. Executable specification can be used to simulate 
different scenarios; the simulation can be animated to enable the designer focus 
on important aspects of the system behavior. 

The proposed approach provides flexibility to test different control functions, 
giving the designer a choice based on other consideration such as throughput, 
passenger comfort (in case of train systems), etc. In this chapter, the primary 
focus has been on safety and the secondary focus has been on maximizing 
throughput. 

The formal model of a train system discussed in this paper relies on discrete 
time model. Such a model can sometimes be difficult to work because it can 
go against the common sense intuition about the behavior of a system that 
is continuous in reality. In [KW01], a continuous time model is developed 
from which the discrete model is derived by proving mathematical properties 
of the equivalence of the discrete model to the continuous model. The paper 
did not discuss how the correctness of both problem independent and domain 
dependent transformations can be established; an interested reader may consult 
[KW01][WKB01] for more details. Also missing from this chapter is any 
formal verification of the control algorithm. 
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7. Appendixes 

7.1 Operational Semantics of Various SPC Constructs 

define list _nm( state, succ, Pred) = if Pred(state) then [state] 

else state:: list _mu( succ( state ), succ, Pred ) ) 



define [set : V] = if isEmpty(set) then SET— EMPTY 

else if V(first(set)) then first(set) :: [set : V\ 
else [set : V] 

Given that SPC restricts its attention to finite sets, filter formulas can also be 
used to define universal and existential quantification. 

■ Vie S,P(x) = ([5 :P] = S) 

■ ].r6 S,P(x) = ([5 : P] f 0) 

7.2 Discussion of the Functionality of Emergency Stop 

A certain amount of complexity arises from the possible interplay between the 
two stopping modes considered. A normal stop is accomplished using normal 
acceleration values, and an emergency stop is accomplished using emergency 
acceleration values. Differing viewpoints can be presented as to the motiva- 
tion behind normal and emergency stopping modes. One possibility is to view 
the emergency stop as a backup braking mechanism. This backup should be 
used in situations where normal stopping is malfunctioning. Though some- 
what counter-intuitive, in this interpretation it may be reasonable to consider 
a worst-case scenario in which it actually takes longer for a train to perform 
an emergency stop than it would using a normal stop. In response to such an 
interpretation, one would have to question why the train could not simply be 
equipped with a redundant mechanism capable of performing a normal stop. 
Thus providing a backup system capable of performing a normal stop. 

A contrasting interpretation is to view an emergency stop as a “hard stop” of 
the type seen in movies when the emergency brake is pulled on a train. From 
this perspective, an emergency stop should bring a train to a halt considerably 
quicker than a normal stop. However, due to the strain on both the passengers 
as well as the mechanical components of the train the emergency stop should 
not be used casually. 

Though the control function developed in this chapter can handle both inter- 
pretations, the state safety policy assumes that an emergency stop should be 
avoided if at all possible. Under normal conditions, a control function should 
only respond to system changes using normal acceleration values. In fact, it 
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is considered a violation of the safety policy for a train to respond to a normal 
environment using an emergency acceleration value. In contrast, an abnormal 
environment permits the control function to consider both normal as well as 
emergency acceleration values. However, in abnormal situations an additional 
subtle requirement is placed on the control function that it must use normal 
acceleration values to establish safe behavior if it is possible to do so. For 
example, suppose a train has derailed on the track 5 miles ahead. As a result 
the train immediately behind (i.e., 5 miles behind) the derailed train sees an 
abnormal environment. Assuming it is possible to do so, this train must come 
to a halt using normal acceleration values. In particular - , it may not continue 
advancing on the position of the derailed train until it can no longer halt without 
availing itself of an emergency stop. Consider the cascading effect that would 
result if a train, upon seeing an abnormal environment, would unnecessarily 
issue an emergency stop. Such an action would be perceived by the following 
train as abnormal which, in turn, would cause it to issue an emergency stop, 
etc., etc. 

7.3 Train Motion in an Iterative Feedback System 

In an iterative feedback system, the equations of motion of a train must be 
computed for each time step from the general function that relates position, 
speed, acceleration, and time. Since the train is confined to the track (at least 
under normal circumstances), we actually have a one dimensional problem in p, 
the position of the train along the track, rather than a three dimensional problem. 
Issues such as track slope can be taken into account through perturbations on a 
train’s acceleration rather than through an independent acceleration variable. 
The following Taylor’s series expansion can be used to describe the behavior 
of a train over a small time interval: 

pit) =p(t Q ) +s{t Q )(t - t 0 ) + ^a(>o)0 - t 0 ) 2 + ••• (2.9) 

In general, the series can be terminated with those terms that are explicitly 
shown. 

In the train controller, we cannot control the position, p, or the speed, s, because 
these two parameters must be continuous. This means that the time develop- 
ment of the position and speed are also continuous. However, we can set the 
acceleration, a, which does not have to be continuous. When we discretize the 
parameters, ( p,s,a ), we are, in effect, selecting the value at the beginning of 
each time interval. This is different from saying that the values are constant 
for the time interval. In such a case, the train would have to violate the laws 
of physics to move. The Taylor’s series can be used, however, to predict the 
values for the train’s motion variables by using the entire time interval in the 
calculation. In this case, we can say 
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p(At) = p( 0) + s(0)At + -ci(0)At 2 (2.10) 

Here, we arc setting a new value for a at t = 0, so the train’s parameters will 
change with time. The speed equation then becomes: 

s{At) = j(0) + a(0)Af (2.11) 

This projection process results in one of the error terms that can affect the 
position calculation of the train. Others can include perturbations on the ac- 
celeration due to slopes of the track, wind speed, track conditions, and others. 
These perturbations of the command acceleration have the combined effect of 
changing the true acceleration from the command acceleration, and therefore, 
the actual position of the train can deviate from the calculated position. In 
an iterative feedback system, the train controller accounts for this deviation 
by getting a report of the train’s position after every time interval (i.e., before 
the deviation becomes too great). The report can then be used to correct the 
commanded acceleration to account for the deviation. 

What we have described, is one way to model the motion of a train in the 
context of an iterative feedback system in which the train’s motion is controlled 
through its acceleration. Note that the model developed cannot assume constant 
position, speed and acceleration over a time interval, since this would violate 
the laws of physics. However, one can assume that the values reported at the 
beginning of each interval are the only ones that arc known, and then use those 
values, which is considerably different. Note that a similar approach can be 
taken when modeling the speed limits of track segments. 

Due to the “drift” that can occur between the model and the actual train system 
some provision needs to be made to prevent a train from exceeding a speed 
limit. One way to do this is to put a guard band on the speed. A guard band is 
essentially a buffer zone that can be used to assure the train’s speed limit isn’t 
exceeded by any process that increases the speed. In such a case, the speed limit 
is not exceeded by virtue of the guard band, whether it is the result of under 
damping in the system, a down slope that the train is on, or some other factor. 
The train will simply set its speed goal at a few (say 3) miles per hour below 
the target speed. This means that while the acceleration is used as a control 
variable, it is the speed that is goal of the command acceleration. Thus one had 
to know the target speed, at the beginning of the acceleration process, so one 
could include that in the calculation of the acceleration profile. The size of the 
guard band would be determined by such things as the expected overshoot. In 
our model, we use such guard bands. For example, if the speed limit of a track 
is 53 mph, then we will model the speed limit as being 50 mph. Note that the 
size of guard band should be determined by a domain expert. 




REFERENCES 



63 



7.4 Extended-BNF Grammar for SPC 

Spec ::= DeOist 

DeOist : := e | DeOist Def ; 

Def : := define InfixPatr = WhereExpr 
| val [rec] InfixPatr = WhereExpr 

WhereExpr ::= Expr [where ( DeOist ) ] 

Expr list ::= [Expr list ,] Expr 

Expr ::= if Expr then Expr else Expr 
| case Expr of Match list 
j fn Match l ist 

| let DeOist in WhereExpr end 
| ForAllExpr 

MatcfOist ::= [Match_List “|” ] Atomic _Match 

Atomic JVIatch ::= InfixPatr => ForAllExpr 

ForAllExpr Mist : := [ForAllExpOist] FORALL InfixPatr IN Expr 

ForAllExpr ::= [ForAllExpr_list :] DisjExpr 

DisjExpr ::= [DisjExpr or_op] ConjExpr 

or_op ::= OR | orelse 

ConjExpr ::= [ConjExpr and_op] NotExpr 

and op ::= AND | andalso 

NotExpr ::= [not_op] ImplExpr 

not_op ~ | not 

ImplExpr ::= [ImplExpr ->] RelExpr 
RelExpr ::= [RelExpr rcl op] InfixExpr 
rel_op ::= = | <= | < | > | >= | != | <> 
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InfixExpr : := [InfixExpr Symbl] E 

E ::= [E + | E -] T 

T ::= [T * | T / ] SubExpr 

SubExpr ::= AppExpr [ “[” Expr “]” ] 

AppExpr ::= [AppExpr] TermExpr 

TermExpr ::= num 

| Ident 

j ( [Expr list] ) 
j “[” Expr : Expr “]” 

Patr_list ::= [PatrJist ,] InfixPatr 

InfixPatr ::= [InfixPatr Symbl] AppPatr 

AppPatr ::= [AppPatr] TermPatr 

TermPatr ::= wildid 
| Ident 

| ( [PatrJist] ) 



Ident ::= alphid 



Symbl ::= symbid 
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From UML to Z 
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Abstract In this chapter, we emphasize a constructive method for managing the complexity 
of large distributed system. The method, so called “Evolutionary” one, is based on 
well known and very simple principles. Designing a complex distributed system 
needs a deep understanding of the Requirements Document. Thus our method is 
mainly a methodology for building trusted system requirement document. It is 
based on mixing both semi formal (UML based) and formal (Z) notations, and 
an incremental process to which Validation and Verification stages are applied. 
Of course the “Evolutionary method” is restricted to the capabilities offered by 
the 2 used notations. In other words we suggest a methodology that warran- 
tees the formal static specification of a distributed system, and that needs some 
complementary tools/techniques warranting the formal dynamic specification. 



1. Introduction 

The development of any system 1 requires to start from a very rigorous System 
Requirements Document (SRD). A SRD is the result of the \ st step of any 
system life cycle. In this step, end user’s needs are elicited, and then an SRD 
is produced. Such a document is of \ st importance. Indeed, as suggested by 
R. Balzer in [Bal85], the qualities of the final system are directly depending on 
the qualities of its SRD. 

How a SRD is produced? A SRD is usually conforming to a standard, as for in- 
stance the Do 178B standard [RTC] commonly used for aeronautics embedded 
systems. Such standards offer strong structuring mechanisms for all the docu- 
ments that should be produced during any development. They help end users, 
and maintainers as well, to walk through the final system documentation. Un- 



* Chapter responsible. 

*By system we mean both hardware and/or software. We do not see any difference between hardware and 
software at the first stage of their development. 
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fortunately standards do not guarantee that documents arc semantically correct. 
Indeed standards arc no more than syntactic frameworks that allow organizing 
the documentation in a rather well fashion. 

How can we help developer teams producing better documents? One solution, 
adopted in many sciences such as Software Engineering (SE), consists of using 
methodologies. A methodology means both a method, a notation, and of course 
some support tools. 

In SE numerous methodologies have been developed since the early 70's. For 
instance, the traditional Water Fall model [Boe76] uses the Descartes’ principle 2 
as explained in [Des56]. It offers a process 3 in which transformational steps 
and Validation and Verification (V&V) 4 means arc considered. 

■ A step is a transformation of input documents into output ones, eventually 
adding some new semantics. 

■ Each step is followed by V&V means. 

- Validation is demonstrated when the output documents preserve (at 
least) paid of the semantics of the input documents. 5 

- Verification is guaranteed by building the output document in a right 
way, i.e. applying the transformation correctly. 

The Water Fall model has given rise to different notations, such as S ADT [Ros77] 
and SA/RT [HP87], Transformational steps are well defined. Unfortunately, 
V&V means arc very often missing. Most often the adopted means for V&V 
arc very basic ones. 

■ Validation is based on Fagan’s principle [Fag76] called inspection, i.e. a 
careful reading of output documents. 

■ Verification is depending on the formalization level of the considered 
notations. Most of them being informal. Verification is limited to a set 
of hints the developer should follow. 

This is because none existing methodology is efficient enough from a V&V 
points of view that we have decided to advocate more specifically the earlier 
phases of any system development. 

In the following we will suggest a real complete methodology based on existing 
notations and their support tools. 



2 The Descartes’ principle is also known as Functional Decomposition or Structured Analysis. 

3 A process is a graphical representation of a method. 

4 Validation is very often considered as the guarantee that the system is correct, whereas validation is con- 
sidered as the guarantee the system has been correctly built. 

5 During the transformation some part of the initial semantics is preserved, not necessarily all of it. 
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2. Technical approach and method 

2.1 Mastering the inherent complexity of systems 

Mastering the complexity of real systems, whatever they arc, requires a strong 
methodology. A methodology is a right combination of both some rigorous 
methods, some well dedicated notations, and a well integrated tool support. 

In SE, structured methodologies have given rise to some many successful sys- 
tems from a functional point of view, but have failed from many other points 
of view, e.g. reusability, easiness to modify, etc. Thus, more recently, some 
other methods 6 have been suggested. Some of them use the Object-Orientation 
principle which puts the emphasize on the data themselves. These methods 
offer both processes and dedicated notations, very often graphical ones. Nev- 
ertheless their tool support is, as for the structured methods, rather poor, i.e. 
limited to syntactical aspects. 

The main reason, which can justify such a poor tool support, is that their no- 
tations arc semi formal. In other words, (we affirm that) V&V means arc 
available if, and only if, a formal semantics can be given both to notations, and 
to processes supporting them. 

Semi formal specification: some benefits. A semi formal notation is a 
notation for which strong syntactic aspects are well defined, but the attached 
semantics is unfortunately not rigorously defined. SADT, SART as notations 
and processes are semi formal. UML [GBR99] as a pure notation is also semi 
formal, even if it is claimed (that paid) of it can be rigorously formalized. 
Fusion [CAB+94] as a process supporting UML notation is very rigorously 
defined, but remains semi formal due to supported notations. 

Regarding these processes and/or notations, it must be noticed their syntax is 
precise but their semantics is rather weak, sometimes not defined at all! 
Nevertheless semi formal notations and their methodological counterparts arc 
in use, and have given rise to many successful systems developments. What 
can explain such a success? 

■ Most often, they arc graphic. In other words they offer a few set of 
intelligible icons and links between them. 

■ They are dedicated to a generic but rather limited area of problems. In 
other words they allow to represent some real situations. 



6 Very often in computer science, method and methodology are considered as equivalent. They are not! Nev- 
ertheless the context is rich enough to help understand if method must be understood instead of methodology, 
and vice versa. 
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Formal specifications: main limits. More or less at the same time semi 
formal methodologies were born, some more formal notations and their accom- 
panying processes appeared [AS80] as well. These very formal 7 notations have 
conducted to many experiments for specifying and developing some (more or 
less) critical systems [ABL97], 

Arc formal methods successful? It must be recognized that they have promised 
a lot since their beginning. Unfortunately their hopes have not been met. It 
is now widely recognized that formal methods can be used for specifying and 
developing very small critical systems. But, as soon as a large system is under 
consideration, they arc not really scalable. Many reasons may explain. 

■ They do not cover all a system life cycle. 

■ They arc based on strong mathematical formalisms that arc not well 
understood by all engineers. 

■ They arc not supported by efficient tools. 

Consequently formal methods arc rarely advocated, except for some dedicated 
fields, where the critically of the system is very high and may dangerously 
compromise its environment. 

The necessary need of semi formal and formal methods. If we compare 
a traditional development based on a semi formal method versus a formal one 
(of course for a small system) it must be noticed that each one offers its own 
advantages and drawbacks, as stated above. 

Instead of being faced to choosing between semi formal and formal methods, 
one may wonder whether their merge can be considered, in order to add their 
advantages, and to remove their drawbacks. 

This is what our approach has considered. Indeed we believe that semi formal 
methods may help giving rise to a first specification 8 . On the other hand it is 
mandatory to guarantee that our first specification is valid. Since formal meth- 
ods allow this, we have suggested to transform any semi formal specification 
into a more formal one in order to validate and verify it. 

Consequently our approach is based on a right integration/merge of existing 
semi formal and formal methods. 



7 Formal is here understood as the fact a unique and precise semantics does exist for any sentence of the 
formal language. It must be noticed that most of our current programming languages are formal, as soon as 
we integrate them with their compiler and their surrounding operating system. 

8 Here specification means both a rigorous description of what the final system should be, and a first design, 
i.e. some right ideas about how it should be built! 
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2.2 The Evolutionary Methodology: its place in system 
development 

The Evolutionary Methodology 9 is mainly dedicated to earlier steps of any 
system development. Indeed, as R. Balzer in [Bal85], we believe that a suc- 
cessful system development is based on a trusted SRD. For this purpose, we 
have adapted a traditional life cycle to which we have added a preliminary phase 
in which we produce a Revisited 10 SRD as shown in Figure 3.1. 




Figure 3.1. Specification phase: where it does take place. 



The input document is an informal one that represents the end users’ needs. It 
can be considered as a preliminary draft of a Revisited SRD. The process we 
suggest for the production of a trusted SRD is as follows. 



9 We call it Evolutionary Methodology because it is largely inspired from the way the UNIX system is built 
as described in [KP]. 

10 Revisited means that the initial SRD has been improved in order to add it right properties, such as validation, 
verification, completeness . . . Consequently we can trust it! 
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■ In step 1 we derive, after a classical analysis, several specifications, each 
one giving a snapshot of the system. Of course there is a small overlap 
between all the specifications 11 . 

■ In step 2 we derive a fast prototype from any specification. Of course 
each prototype is directly depending on the kind of specification we arc 
considering. For instance, for a functional specification, we may develop 
a fast prototype, i.e. a program written in some dedicated language such 
as Prolog, we can test. For an interface specification, the fast prototype 
could be summarized by a set of figures. 

■ In step 3 we tune the under considered specification. Tuning here means 
updating the specification is such a way that his/her developer is confident 
enough! 

■ In step 4 we validate the specification. In other words, taking advantage 
of the fast prototype previously developed, we ask one end user to validate 
it, i.e. to check whether the specification meets his/her requirements. Of 
course, depending on his answer we adapt the specification, regarding a 
new analysis any time the specification is invalidated. 

■ In step 5, it is sometimes mandatory to come back to the initial end 
users’ requirements, and to change some of them. Indeed end users’ 
requirements arc sometimes inconsistent: they must be modified, at least 
updated, when contradictions arc discovered. 

■ In step 6 all the specifications arc gathered into one, and only one, docu- 
ment which will be a trusted SRD that we call Revisited SRD. It must be 
noticed that standards play here an important role. Indeed in any standard 
all the chapters refer more or less deeply to the different specifications 
that arc considered in Figure 3.1. 

■ In step 7, the system development process can be started, accordingly the 
chosen methodology. 

Why can we assert that we produce a trusted SRD? Three main reasons can be 
advocated. 

■ One is relative to the fact that we consider in our schema all the specifi- 
cations that arc expressed, more or less explicitly /implicitly, in the initial 
SRD. Each specification is the right representative of at least a point of 
view some end users have on the system to be developed. 

1 1 In the following we concentrate on the functional specification, but all the subsequent steps must be used 
in the same way for the other kinds of specification. 
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■ The second is relative to their validation by the way of some fast proto- 
types. It is mandatory that end users agree on all the specifications, i.e. 
end users' point of view, that arc produced by the specification team. Of 
course each specification validation involves the end user who has ex- 
pressed the point of view that has given rise to the dedicated specification. 

■ Finally the traditional standard for documentation is decomposed into 
chapters, each one encompassing at least one of the end users’ point of 
view on the system. Thus we may assert the SRD is complete. 

An important remark must done at this level. It is clear that our suggestion 
introduces 3 different teams, instead as usual, 2 teams. Indeed we believe that 
a new phase must be considered: the specification phase. This phase should 
be done by people with right knowledge, that is to say (1) people being able to 
understand the problem they have to specify, and (2) people able to formalize it 
in such a way that its functional and non functional properties meet the end users’ 
needs, and can be transmitted as such to the development team. According us 
the role of each team must be as follows. 

■ The customer team is in charge of producing the l ' 7 document (a kind of 
SRD representing the end users’ needs), and as well later on to validate 
the revisited SRD. Indeed the design, and the development can staid, if, 
and only if, the customer team agrees with the trusted SRD. Thus the 
customer team is part of the validation process. 

■ The specification team is in charge of transforming the end users’ needs 
into a more formal document, the Revisited SRD, that is used in the 
subsequent development. It must be remember that most often the de- 
velopment team is never in contact with the end users. Consequently, 
if the Revisited SRD does not really represent what the end users have 
in mind, many mistakes corresponding to wrong decisions taken by the 
development team may occur. This is the reason why the specification 
team must deliver a valid and complete SRD 12 . 

■ Finally the development team is in charge of developing the system. As 
written above, because the developers arc very seldom interacting with 
the customer team, it is mandatory they have in hands a document they 
may question, and of course in which they will find right answers to their 
questions. 

Having defined and justified the context of our approach it is time to describe 
it in more details. 

'^Complete means here that any question the development team may ask will find its answer in the specifi- 
cation, i.e. in the Revisited SRD. 
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2.3 The Evolutionary Methodology: a brief overview 

We present a methodology for specifying functional and non functional prop- 
erties of any system, as far it is possible. We consider any kind of system i.e. 
system including hardware and/or software. 

Our methodology respect some very simple principles. 

■ We do not propose new formalisms. Therefore we arc considering how 
it is possible to integrate consistently different notations for the Require- 
ments Engineering (RE) phase. 

■ Our process is a new one. It is detailed below. 

■ The support tool we recommend is based on existing ones. 

We show that translating the functional part of a SRD into some UML Class 
Diagram [GBR99] is the right way to start the Elicitation phase. 

After a mandatory Validation phase, we show how it is possible to transform 
the elaborated Class Diagram into formal Z [Spi89] state spaces, to which 
invariants representing some global functional and non functional properties 
the system must satisfy may be added. At this stage it is obvious that we have 
given the specification much more semantics because we arc able to tackle some 
global constraints. 

We then specify formally the operations/services that the under considered sys- 
tem must offer. Taking advantage of the Z notation we verify the specification 
from 3 different points of view. 

■ We first of all evaluate its satisfiability, i.e. whether the specification is 
meaningful. 

■ We then check its consistency, i.e. whether there is any contradiction 
between the offered services. 

■ And finally we build a robust specification, i.e. we check whether each 
event considered in the initial SRD has been completely specified. 

Again a Validation phase allows to be sure we have treated the right problem. 
We end up the formal Z specification by a Reverse Engineering phase which 
consists of translating both the semi formal and formal specifications into some 
informal ones, in order to allow end users validating them by a care ful inspec- 
tion. 

3. Our approach in details 

As written above, our approach is based on a right integration/merge of semi 
formal and formal notations. What we have chosen? And more importantly 
why? 
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We have decided to integrate both (the set of) UML notation(s), the object- 
oriented process supported by the Fusion method, and the Z formalism. 

■ The UML notation is a de facto standard. It allows to describe, in a 
graphical way, all the different points of view that end users, developers 
and maintainers might have on any system. 

■ Fusion offers a very rigorous process, covering all the aspect of any 
system life cycle. For each step, real V&V means arc considered, even 
not totally formal. 

■ The Z formalism seems to be, at the time being, the most appropriate 
for describing sequential 13 system at earlier stages of its development. 
Moreover it is simple enough to be understood by any developer, and 
benefits from some industrial free tool support. 

An important question: why introducing Z instead of Object Constraint Lan- 
guage [OMG] (OCL) the last notation introduced by the OMG? 

OCL, as recognized by its developers, is a formal notation for describing pre- 
and post-conditions, class invariants, etc. It is largely based on Z subset. Un- 
fortunately OCL does not offer, as Z, some underlying method for checking 
the consistency, robustness and satisfiability of any formal specification. It is 
neither supported by industrial tools. Thus it is more appropriate to use Z than 
OCL. But be sure that as soon as OCL evolves enough it will be the right answer 
to combining semi formal graphical notations and formal ones. Chapter ?? will 
introduce the OCL point of view of the BART system. 

3.1 The global process 

Having introduced the used notations, it is time to consider how these notations 
arc used, when, and of course for what purpose. This can be summarized by 
Figure 3.2. 

From a macroscopic point of view 4 main phases arc considered. 

■ In phase 1 (we call it 1 st analysis) we derive, after a careful reading/analysis 
a macroscopic architecture of the (future) system. This architecture is 
made of the identification of the macro components, and their relation- 
ships. We identify during this step what should be the (more or less) 
independent components, and what arc the nature of the links between 
them. We use the word architecture but from a pragmatic point of view, 
the main result of this phase is the set of identified macro components that 



13 The Z notation allows to specify more than sequential systems. But it is wise to consider an extension 
called Temporal Logic of Action, developed by L. Lamport [Lam94]. 
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Figure 3.2. Macroscopic view of the Evolutionary Methodology. 

constitute our final system. It must be remember that we specify a system 
that is not necessarily new, i.e. it may still exist some components that 
must be clearly identified, as for the new ones. The objective is to be able 
to further split the architecture in such a way that the global specification 
could be composed of (more or less) independent sub-specifications. 

■ In the second phase we build the real architecture of the system according 
to the identified components. The architecture is only static, that means 
we again identify its microscopic components, in the same way it is rec- 
ommended by all the object-oriented methods. In other words, for each 
component we build a Class Diagram that represent all the abstract ele- 
ments of the under consideration component. Again it must be noted that 
we do not describe a solution, we just clarify the end users’ needs as a set 
of interacting objects, abstracted through classes, and some relationships 
between them. 

■ In the third phase we give a formal semantics to the operations of each 
identified class. Here is the core of our methodology. Indeed, to some 
respect the above phases arc equivalent to those ones recommended by 
other object-oriented methodologies. We suggest to give the semantics 
of operations in an iterative and incremental manner. The iterative aspect 
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is still present in Figure 3.2 with the return actions allowed by arrows 3 
and 6. The most important is in the incremental manner we develop both 
the static architecture and the formal specification of operations. This 
will be explained in next section. 

■ The fourth phase is the last one of our methodology. It is a Reverse 
Engineering phase that consists of translating the semi formal and formal 
models into some informal texts, each one being (partly) split into the 
different chapters of the standard used for the SRD. 

3.2 Giving consistent semantics to operations: an iterative 
and incremental cycle 

The core of the Evolutionary Methodology is given in Figure 3.3. As soon as 
a static architecture is designed, how it can be validated? In classical Object- 
Oriented methods, the Fagan’s principle is extensively used. Unfortunately we 
do know this is not sufficient. Many subtle mistakes arc often not discovered 
even after a deep reading. 




Figure 3.3. The iterative and incremental cycle of the Evolutionary Methodology. 

The core of the Evolutionary Methodology allows to overcome such a problem. 
How do we proceed? Let us consider that we have still built an intermediate 
formalized and validated specification, as in Figure 3.3 for instance Increment 
i . We then introduce an increment, let say i+1. By definition an increment is 
the adding of new elements, both in the semi formal specification, and then in 
the formal one. 
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Briefly sketched, we build an increment as follows. 

1 We first of all extend the static semi formal architecture by adding some 
new elements to the Class Diagrams of Increment i. These extensions 
can be either attributes, operations, classes and/or relationships. They 
generate a new increment, e.g. i+1 that must be validated. As it is semi 
formal it is validated by a deep inspection. 



2 We then formally specify the increment i+1 in formalizing its new el- 
ements. This is represented by specification arrow in Figure3.3. The 
transformation of semi formal elements into formal ones is possible thank 
to a set of transformation rules we have introduced in [LTW98]. They 
arc recalled in section . It must be noticed that sometimes it is not easy 
to give a semantics to a post-condition. In such a case, one must wonder 
why the specification of the post-condition is so difficult to get. Most 
often this difficulty is the explicit sign that the semi formal extension, I.e. 
increment, is not collect. 



3 At this level we are now able to formally validate the formal increment 
i+1. Indeed as recommended by the Z methodology [Spi89] a Z formal 
specification must possess 3 main properties: satisfiability, consistency 
and robustness. The one we will apply here is the consistency. What does 
it mean? We must demonstrate that there does not exist any contradiction 
between the formal specification of any operation and the current class 
invariants. In other words, it must be proved that the post-conditions of 
any formal operation are not in contradiction with all the class invariants 
where the operation takes place, or with any generalized class of the class 
hierarchy to which the current class belongs. 

The result of this step is either a proof that operations arc consistent, 
or the demonstration they aren’t. In the former we can go on adding 
new increment because we have validated the increment i+1. In the 
latter we have discovered an inconsistency, i.e. we have demonstrated 
the specification is not valid. 

We then arc obliged to go back. Where we have to go back? First of 
all we have to discover what is wrong! Is it the formal increment? Is 
it the semi formal one? Or both? The section tries to answer these 
questions. 

The above explanations justify why we qualify our approach as Evolutionary! 

It is iterative and incremental. 
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3.3 Building the kernel 

We have presented the way both we build increments, and we validate them 
formally. It is time know to consider how we build the first increment so called 
the kernel. 

The kernel is the formal direct translation of one, or a few, chosen class(es) 
from the static model. What class(es) to be chosen? It is up to the customer 
team to select it (them). We recommend to proceed as follows. 

■ The (set of) class(es) must be small enough, i.e. not having too many 
attributes nor too many operations. 

■ The only relationships that appeal - must be associations, i.e. strong links 
between objects, instances of selected class(es). 

■ It must be stable enough, i.e. that will not evolve at all. 

■ It must have a precise semantics, i.e. the customer team must known 
it, and consequently, must be able to guarantee that its inspection is as 
strong as a formal validation. 

In other words it is mandatory that the customer team chooses a few potential 
classes that meet the above requirements. The kernel will be built from one, 
or more, potential class(es). It is important to select classes that have no in- 
variants. Indeed when none invariant is available then demonstrating operation 
consistency is useless. But of course, if the selected initial class has invariants, 
as soon as we translate it formally according to , we get a formal specification 
that must be checked vs consistency, if needed. 

This formal kernel is the stable basis from which all the subsequent increments 
will be set up. 

3.4 Building the Revisited SRD: a Reverse Engineering 
phase 

We are now arrived at the latest step of our methodology, i.e. the generation 
of the Revisited SRD. As written above, we call it Revisited or trusted SRD 
because the elements we will using for its generation are of confidence. 

The generation process is rather simple, and systematic. We must translate all 
the semi formal and formal models developed during our process into informal 
texts. Thus it is a Reverse Engineering phase. More preferably this transla- 
tion should be done by a person knowing the problem in hands and the used 
notation . 14 

14 It will be better to ask two different people to do this work because the semi formal and formal specifications 
use two different languages, even a set of transformation rules exist between UML and Z. 
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After gathering all the informal texts, the process of building the Revisited 
SRD consists of copying/pasting (parts of) those informal translated texts into 
the standard chosen for SRD, in the same way we fill-in-a-form. This work 
should be done very seriously in order to guarantee none field is missing. 

In the above Reverse Engineering phase we consider that any part of the semi 
formal and formal specification can be, after being translated into an informal 
text, past into some chapter, section, subsection, etc. of the standard in use. This 
is always true. Indeed our semi formal and/or formal specification is related 
to functional and non functional properties of the under consideration system. 
Even during the check of the completeness of the formal specification during 
which some functional/non functional properties could be added independently 
of the initial SRD, there exist a slot for them, i.e. they address at least one of 
the sections of the standard we use. 

3.5 About the Z underlying method 

These sections are here for the reader not familial - with the Z method. We 
first of all describe the object-oriented aspect of the Z notations in introducing 
some transformation rules that allow to convert any Class Diagram into a Z 
specification. We then explain what are the main properties a right Z specifi- 
cation must have, and finally we give some hints to improve/update a formal 
specification when an inconsistency is discovered. 

From UML Class Diagram to Z notations. As stated above it is important 
in a right process not to let the developer faced to too many decisions. Thus 
we have suggested a few transformation rules between UML Class Diagram 
notations into Z notations. This is summarized in the following table. 



Class 


State Space 


Attribut 


State Space Variables 


Operation 


Operation Schema 


Relationship Aggregation 

/ Composition 


Ad hoc Structure 
(list, set, etc.) 


Specialization 


Schema Import 


Association 


Cartesian Product 


Class Invariant 


State Space Invariant 



Table 3.1. Transformation rules 



Satisfiability, consistency and robustness: properties that any Z specifi- 
cation must meet. The Z underlying method obliges to demonstrate that 
a given Z specification must be both satisfiable, consistent, and robust. Very 
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briefly, these properties refer to some mathematical background we introduce 
here. 

Satisfiability A Z specification is satisfiable if there exists at least an initial 
state space that satisfies the invariants. An interpretation of this property 
is to say that a specification is meaningful, i.e. it can be constructed. 

It must be noticed that it does not mean the specification is semantically 
correct. 

Robustness A specification is said robust if, and only if, we can demonstrate 
that all the cases or events envisaged by the end users requirements have 
been considered. The reader familial - with industrial problems should be 
convinced that this property is the most important one. Indeed industry 
does not expect that all the systems are semantically correct and well 
implemented, but at least all the cases or events that may happen have 
been considered. 

The Z method offers a very powerful means to build robust specifica- 
tion. We have not presented it in the above part. Indeed the robustness 
property is set up during the formal specification of the system behavior. 
We formally describe the system behavior as a set of formal statement 
where static operations are linked using classical control operators . 15 As 
soon as (part of) a behavior is described we must demonstrate that its 
pre-condition is true, i.e. whatever is a considered event it has been taken 
into account by the formal specification. If we are not able to demonstrate 
such a property we must add new formal operations that help demonstrat- 
ing that the global behavior is true. These new operations are given the 
semantics of the unspecified answer of expected events. A direct conse- 
quence of adding new operations is that the initial SRD can be declared 
as incomplete. 

Consistency The third property has been presented above. It is not necessary 
to recall it. 

Improving increments. One may wonder what should be done when an 
inconsistency is discovered. The Z method does not help at all. 

Fortunately our experience in formalizing specifications has suggested a few 
recommendations we would like very much to share. Indeed when the post- 
condition of an operation is inconsistent, i.e. violates at least one of class 
invariants we must first of all consider either to change the specification, or to 
weaken some invariants. Indeed we must first of all wonder whether we have 

15 Classic control operators are: sequence, iteration/loop, condition, block, concurrence, etc. 
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not introduced a wrong specification. For this purpose we reuse a very simple 
technique. We ask another person, not having developed the specification but 
knowing both the domain of the problem and the Z notations to translate the 
post-condition into some informal text. It is very surprising how the translation 
is able to reveal mistakes! 

When we arc convinced that the semantics we have given to the operation, 
i.e. its post-condition is right, we then must weaken some of the invariants. 
Weakening invariants means either removing some of them, or lessening pari 
of them, if it is possible. 

And only if both above techniques do not give rise to a consistent specification, 
we then must reconsider the semi formal model. We arc then faced with a 
problem of validating a semi formal model, as usual. 

Our experience has shown that this above corrective process is efficient enough 
in most cases. 

4. Inputs taken from the BART case study 

The BART system, as described in Chapter 1, is a complex system. The re- 
quirement document presents both functional and non functional properties. 
Moreover, some parts arc very detailed whereas some arc rather highly de- 
scribed. 

How can a such huge amount of more or less interdependent information can be 
represented, i.e. modelled in such a way we can master its inherent complexity? 
The Object Oriented approach suggests, as for instance according to the Fusion 
method [CAB 1 94], to design, after several steps, a Class Diagram in which 
mainly analysis classes and their relationships arc identified. 

The class diagram which is presented in Figure 3.4 is pari pari of a static view 
of the BART system. Here we have restricted the class diagram to a subset 
which encompasses tracks. 

Instead of describing it in details, we will concentrate the discussion on the 
means Object Orientation provides for validating static and dynamic models. 
This incomplete model 16 cannot be easily validated. Indeed, two independent 
means can be used to (in)validate 1 7 the model: 

■ Cross reading, as usually performed for inspections. 

These inspections arc a means, for end users and inspectors, to warrantee 
that designers have understood the problem! 



16 This model is incomplete for many reasons: for readability purpose, only classes identifiers have been 
identified; associations are not labelled since their semantics is obvious. 

17 It must be noticed that usually invalidation is easily reached, as soon as inconsistencies are discovered. 
Unfortunately validation can never be reached! 
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Figure 3.4. The Tracks & Co component. 



■ Traceability matrix that can be drawn between a model and the require- 
ments document. 

With a traceability matrix, it can be demonstrated that none of important 
requirements has been forgotten! 



At the end of this V&V process, designers can not be formally convinced, i.e. 
no real proof is exhibited, that their design is consistent, nor complete ! On the 
other hand, we will show, as suggested by the Evolutionary approach, how such 
properties can be reached. 

5. Applying the approach to the case study 
5.1 Specifying the BART system 

As suggested by the Evolutionary approach, we have considered a small stable 
kernel. This small kernel is mainly based on blocks, and trains. Before devel- 
oping the specification, it is mandatory to introduce a few notions, as global 
types, and global functions. 
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5.2 Global Functions and types 

We need specifying a few functions and types that are reused further in our 
specification/design. 

\ I DENT] 

GRADE == -400 . . 400 
WAY ::= west \ east 

■ IDENT represents any identifier 

■ GRADE represents the notion of grade as defined in the BART Require- 
ments Document. 18 

■ WAY is an indicator used in TRAIN and SEGMENT to precise their di- 
rection. Thus, for any train rolling on any segment, their way must be 
the same. 

5.3 Modelling the BART topology 

Basic types. Requested basic types are TRAFFIC LIGHT and POINT. 
TRAFFIC ALIGHT ::= green \ red 

A TRAFFIC LIGHT is an abstraction for a gate. It can be either red, corre- 
sponding to a closed gate, or green corresponding to an opened gate. 

POINT 

Z : Z 
x : N 

id : IDENT 



Here we arc obliged to specified what is missing in the RD. Indeed a main 
question is: how trains arc located on tracks? This information is implicitly 
given in the table that summarizes the type of information attached to tracks 
segments in the requirements documents. Thus we have introduced a POINT 
as a basic type. We have been obliged to specify it as a 3-uple where z is its 
altitude, x a curvilinear abscissa with value 0 at the starting point of the track, 
and id its identifier. 

compute length : POINT x POINT — ► N 

compute -grade : POINT x POINT x IF POINT -> GRADE 

These 2 functions arc needed to know both the distance, i.e. the length, between 
2 points, and the grade associated to any couple of points. 

18 In the following, RD for short. 
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BART infrastructure description. A SEGMENT is modelled as a couple 
of POINT , with an identifier (missing from the RD), a length, a type of grade. 

SEGMENT. 

SEGMENT 

id : IDENT 
entry, exit : POINT 
length : N 

parabolic _grade : F POINT 
grade : GRADE 
speed-limit : N 
trains seq : iseq TRAIN 
way : WAY 

entry exit 

length = compute Jlength(entry, exit) 

Uparabolic-grade < 1 
speed-limit £ 36 . . 80 

grade = compute— gradeientry , exit, parabolic -grade) 

entry. x < exit.x =>■ way = east 
entry. x > exit.x => way = west 

V t : TRAIN | t £ ran trainsseq • t.way = way 

V t : TRAIN | t £ ran trains seq • t. actual speed < speed-limit 

V i : N | i £ 1 . . ^trainsseq 

• compute-distance(trains_seq(i) , trains_seq(i + 1)) 

> cornpute-dwc(trainsseq{i +1)) 

V t : TRAIN | t £ ran trainsseq • 

t.begins.x £ entry. x . . exit.x 
V t.begins.x £ exit.x . . entry. x 



Over the horizontal bar we declare variables. Here we give a comment for 
trainsseq. It is declared as an injective sequence, i.e. a FIFO. Indeed it is 
mandatory to manage trains on a segment in such a way they can be easily 
ordered. A traditional FIFO sequence seems an adequate structure. 

The invariants are specified under the horizontal bar. 

■ The entry point and the ending point of any segment are different. 

■ For all trains of a given segment, their way must be the same than the 
segment way they run on! It must be remembered that there exits way 
(east/west) in the BART system. 

■ For all trains of a given segment, their speed must be less than segment 
speed limit. 

■ For all trains of a given segment, their separative distance must be greater 
than a value given by an ad hoc computation. 
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■ The last invariant specifies the fact that we consider trains as being totally 
include in a segment. In other words, because we arc inside a segment 
we do not specify that the separative distance between the last train of a 
segment and the first train of the next segment is guaranteed. 

NB: we arc pretty convinced there exists a relationship between grade and 
speedJUm.it. But the BART RD does not say anything about this. 

We arc now ready for specifying an increment in which we will introduce the 
notion of BLOCK. 

BLOCK. 

BLOCK 

block : iseqSEGMENT 
previous , next : F SEGMENT 
gate : POINT — TRAFFIC-LIGHT 
way : WAY 

j^block > 1 

Unblock > l => head (block) ^ last (block) 
previous n ran block = 0 
next (~| tan block = 0 
# previous < 1 
d^next < 1 

3 si, se : SEGMENT \ si £ previous A se £ next • 

si. exit = (head block) .entry A se. entry = (last block). exit 

V i : N | (i > 1 A i < #b!ock) 

• ( block(i)) .exit = (block(i + 1 )).entry 

#gate = 1 

dom gate = {(head block) .entry} 

V 5 : SEGMENT \ s £ ran block • s.way = way 

V i : N | (i > 1 A i < j^block) 

• compute -distance (last ((block(i + 1)). trains seq), 

head ( (block(i)).trains_seq)) 

> compute_dwc(head ((block(i)) .trainsseq)) 



■ A BLOCK is a sequence of continuous SEGMENT s. 

■ A BLOCK can be isolated, or continuing with at maximum one segment 
at each end. 

■ A BLOCK has one and only one gate at its entrance, where there arc 
traffic lights. 



A BLOCK must have no loop. 
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■ There exists at least one SEGMENT in a block. The RD does not say 
anything about the emptiness of a BLOCK. Moreover for each SEGMENT 
its end is equal to the beginning of its successor neighbor. 

■ The last invariant states that the separative distance between the last train 
of a segment and the first train of the next segment is guaranteed. 

SWITCH. 

SWITCH 

links : F BLOCK 
way : WAY 

V b : BLOCK \ b £ links • b.way = way 

#{t : TRAIN | {3b: BLOCK ; 5 : SEGMENT \ s £ ran b. block 
• t £ ran s.trainsseq) • t} < 1 



A SWITCH is a set of BLOCKS (bordered by gates). Each possible trip in the 
switch is defined by a specific block. So, blocks included in a switch do share 
some segments. Switches arc small spaces. We consider that there is only one 
train maximum at a time in a switch. 

AREA. 

AREA 

ctEarea, info-area : W(iseqBLOCK) 
switches : BLOCK -++ SWITCH 
way : WAY 

V b : BLOCK ; sb : iseq BLOCK \ b £ ran 5ft A sb £ info_area • b.way = way 
ctEarea C info_area 

dom switches = {b : BLOCK ; 5 W : SWITCH ; sb : iseq BLOCK \ 
b £ sw. links A b £ ran sb A sb £ info_area • ft} 

V 5i,52 : SEGMENT ; sb : iseq BLOCK \ sb £ info_area 

A 5i = head ((head sb) .block) A 52 £ (head sb) .previous 

• compute _jdistance(head si.trains_seq,head (s^-trainsseq)) 

> compute-dwc(head (s 2 .trains_seq)) 

Vi : N; 5ft : iseqBLOCK \ (i £ 1 . . #sb — 1) A sb £ info-area 

• compute_distance(head ((head ((sb(i + 1)). block)). trains_seq), 

last ((last ((sb(i)) .block)) .trains_seq)) 

> compute_dwc(last ((last ((sb(i)). block)). trainsseq)) 



Each control station controls an AREA. An area can’t be considered as a 
sequence of BLOCKS because it may contain switches and convergent tracks. 
An AREA gets information of consecutive BLOCKS that it does not control! 
As for SEGMENT , and BLOCK , the separative distance between trains is for- 
mally specified. 
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TRAIN. 

TRAIN 

id : IDENT 
length : Ni 
begins : POINT 
actual speed : N 
actual_accel : N 
actual-brake : N 
way : WAY 

actual_speed < 80 

actuaFaccel < 300 
actual-brake < 200 

actual-brake ^ 0 => actual-accel = 0 
actual-accel A 0 => actual-brake = 0 



Finally a TRAIN is (partially) specified. The physical acceleration is split in 
2 parts: actual _accel describes the increase of the speed and actual -brake 
describes the decrease of the speed. These 2 values are natural. 

compute_distance : TRAIN X TRAIN — ■> N 
compute_dwc : TRAIN — ■> N 

The function compute-distance evaluates the distance between two trains, tak- 
ing into account the very beginning of the second train and the very end of the 
first one. 

The function compute dwc computes the braking distance in worst case. 

NB: We don’t specify compute dwc because it is fully described in the BART 
requirements document. Nevertheless, we guarantee that its profile is rich 
enough to compute the result. 

6. Results raised by this technique 

In the preceding, we have just sketched what should be a real static formal 
specification of the BART system, according the the Evolutionary approach, 
using the Z notations. 

Many points arc missing. First of all, we have not specified operations that 
modify and/or access state space. Nevertheless, even without specifying oper- 
ations, it is important to show we can exhibit some static properties the BART 
system must permanently meet. Here these properties arc security ones as, for 
instance, the separative distance between trains, in any conditions. 

A second important results is our ability to give semantics to operations, from 
a static point of view. Indeed, as cited in [Spi89] but not shown here, Z allows 
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to formally specify sequential systems. In the context of the BART system, 
we have been able to give semantics to operations such as changing traffic 
lights, and of course its subsequent impact on the train movements. It can be 
easily demonstrated that for consistency reasons, train movements are directly 
dependant in traffic lights. And on the other hand, traffic lights can’t be changed 
independently of train movements on a given tracks controlled by a gate, acting 
on the traffic light. 

Nevertheless, the main results of the Evolutionary approach concern the matter 
semi formal models (as those provided by object orientation) can be invali- 
dated, and consequently, must be improved, i.e. completed by more formal 
notations, such as Z. It must be noticed that there now exist many formal no- 
tations for specifying system, at a rather low level. For instance OCL [OMG] 
for UML, and JML [groOO] for Java. These 2 formal notations can surely be 
used in industry, at an implementation level. But they lack of abstraction. In 
other words, there is a need for formally specifying systems, and for studying, 
before any implementation, and even more before any prototyping phase. This 
specification step will help demonstrating that some very important properties 
of any system are reached. In the case of the BART, the main Quality of Service 
(QoS) is security. A rigorous specification helps reaching this QoS! 

7. Conclusion 

It is clear that some formal notations, such as Z, can be used to specify what 
the system should do. It is very important to agree on the main objectives 
the system must satisfy. Here is an important trick! How can the end users 
guarantee they have in hands a system that meets their requirements? Usually, 
only once a first version of the system is delivered, and when it can be directly 
tested. Unfortunately it is too late! 

What does the Evolutionary Methodology suggest? In no way it is a method- 
ology to find out a final solution to a problem. It is an accurate way to help end 
users expressing formally their needs. As stated above, formality is mandatory 
to meet requirements. End users’ requirements being informal, it is mandatory 
to transform them in such a way that they become formal. Once they have been 
formalized, many different approaches arc available w.r.t. the V&V problem. 
In the Evolutionary Methodology an emphasis is given to the way we move 
from informal requirements, to semi formal ones using the UML notation, and 
to the very formal ones using Z. We have suggested an incremental process, in 
which many small V&V steps arc available. 

Formalizing requirements has many advantages ! End users can be sure their 
requirements have been correctly understood, and vice versa, the development 
team is sure to correctly understand what is needed. Moreover, end users will 
not been expecting much more than that has been formally expressed. 
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Abstract This chapter uses the Unified Modeling Language (UML) and the theorem prover 
pvs to formalize and analyze a part of the BART/AATC system. Our approach to 
the formalization and analysis takes five steps within which we iterate a number 
of activities, both for constructing and validating UML diagrams of the system. 
We find inconsistencies and omissions in the informal requirements specification 
and produce a formal specification which we can use for further system design. 
A simple UML model of the behavior of the train is created, and a controller is 
designed and proven to be correct within that model. 



1. Introduction 

It is well-known from the literature [Rus93, Som92] that mistakes in the re- 
quirements of a computer system propagate through all phases of the software 
development process. The later a mistake is discovered, the more expensive 
it is to repair. Requirements documents can be incomplete, inaccurate or in- 
consistent, and it is important to be able to detect mistakes from all 3 of these 
categories. Finding and repairing these defects early in the development cycle 
improves the quality of the software and reduces costs. 

Our research aims to improve the quality of requirements specifications. This 
means that we want to detect omissions, falsehoods and contradictions in re- 
quirements documents that arc written informally in natural language. To do 
so, we use a semi-formal notation that contains no ambiguities and that makes 
it possible to analyze the requirements documents for these defects. The semi- 
formal notation should be useful for the rest of the development process as well. 
Otherwise, it is far too likely that the results of the formalization and analysis 
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will be disregarded, leaving the rest of the development process to contend with 
exactly the same inconsistent, inaccurate and incomplete informal requirements 
document we started with. We will demonstrate how an approach to require- 
ments specification using formal methods detects and repairs errors. 

In the embedded systems field, more than anywhere else, systems arc built for 
a particular environment which is reasonably well understood. Embedded sys- 
tems arc also often safety-critical systems, meaning that their safety properties 
within their expected context need to be checked with the greatest rigor and 
accuracy. This implies that we need an accurate model of the environment. We 
also need a model that is as complete as possible, showing all of the relevant 
behaviors that occur in the environment. An environmental model can be con- 
sidered part of the requirements of an embedded system because the system is 
specifically intended to operate in such a context. 

In this chapter, we produce a formal model of the environment of the AATC. 
This model contains many simplifications, and concentrates on the physics of 
the trains, the behavior of the train controller, and the communication between 
the train and the AATC. 

1.1 Structure of this Chapter 

The remainder of section 1 is devoted to giving a general overview of our 
approach, the manner in which we apply it, and the scope (within the BART 
case study) of our approach. 

We detail the steps of our approach with particular attention to the special needs 
of the BART case study in section 2. We apply some of the steps of our method 
to the BART case study in section 3. 

1.2 Overview of our Approach 

We begin with a high-level overview of our approach to improving the quality of 
the formal requirements derived from a given informal document. Our approach 
consists of 5 steps, which can be found in the literature [Dou99] as well: 

1 Clearly separate the system under development from the environment in 
which it will operate. 

2 Model the environment in a formal fashion. We apply several iterations 
of a construct-and-validate approach to analyze and validate the environ- 
ment model. 

3 State the properties which the system under development is required to 
realize in its environment. 

4 Do some very limited high-level design of the system under development. 
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5 Check the properties against the high-level design and the model of the 
environment. 

The last 2 steps arc not essential to the formalization of the requirements, but 
serve as useful additional checks that the requirements arc consistent and real- 
izable. In addition, the high-level design could be used in further development. 

1.3 Choosing Notation and Tools 

Our approach is in principle independent of any particular notation. Any real 
application, though, needs an agreed-upon notation that meets a few require- 
ments. The notation must be usable for further software development. In 
addition, in order to perform steps 2 and 3 of our approach, we need a notation 
that is sufficiently formal for analysis. 

The Unified Modelling Language (UML) is a reasonable choice for notation 
for our method. Since UML is becoming the standard notation for industrial 
software development, using it has the advantage of connecting well with the 
rest of the development process. In addition, there is ongoing work [DJVP03] 
on giving parts of the language a formal semantics so it is usable for analysis 
as well. 

To analyze a requirements specification formally requires a formal representa- 
tion of the UML model in some suitable formal language. Various theorem- 
proving tools [ORS92, JLXOO] are available with which we can formalize the 
UML diagrams. Model-checking tools [LPY95] could be used as well. We 
choose to use the theorem prover pvs based on the expressiveness of its lan- 
guage and previous experience with the tool. 

Our use of the UML and pvs in formalizing the requirements specification is: 

1 We draw a UML Use-Case Diagram in order to delineate the border 
between the system and the environment. This is often unclear in informal 
requirements documents, where details of both system and environment 
arc mixed together. We use Use-Case Diagrams (standard technique) to 
delineate the border. Both Class Diagrams and Message-Sequence 
Charts are used to discover the border and to document details of that 
border. 

We detail this step in section 2.1, and apply it in section 3.1. 

2 The development of a model of the environment proceeds iteratively: We 
alternate between phases of construction (finding structure and behavior) 
and phases of validation (tracing, checking forms, and checking mean- 
ing). Structure is captured in Class Diagrams, while behavior is written 
down using StateCharts. 

This can be seen in sections 2.2 and 3.2. 
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3 Formalizing properties of the system under development is an activity 
that proceeds iteratively much like the development of the environmental 
model. In this chapter we do little work with the requirements themselves; 
see [dGHOO] for a detailed illustration of how we deal with formalizing 
the properties of an embedded system. This step produces mathematical 
formulas stating relationships between quantities mentioned in the Class 
Diagrams. 

4 High-level design is beyond the scope of this chapter. Our demonstration 
here is limited to a single iteration of the constructive phases of our ap- 
proach to step 2. Our high-level design consists of more Class Diagrams 
and StateCharts, similar to our model of the environment. 

5 Checking properties of the model and the design requires tools all its 
own and is also beyond the scope of this chapter. We will give a small 
demonstration, though. This yields a number of PVS theories and proofs. 

1.4 Purpose and Scope 

We wish to demonstrate that our 5 -step iterative approach — and in particular 
the iterative approach to the formalization of the environment — is a useful 
tool in improving the quality of a requirements specification and can produce a 
formal requirements specification that is useful in further software development. 
In particular, we hope to identify and resolve incompleteness, inaccuracy and 
inconsistency within the given informal document. 

In order to perform all 5 steps of our approach within the space of this chapter 
we have selected a small but representative part of the BART case study to 
examine. We have chosen to model the behavior of the trains of the BART 
system with some simplified physics. These trains arc the environment of the 
AATC system that needs to be designed, so we can highlight steps 1 (boundary 
definition) and 2 (environmental modelling) of our approach. We restrict our- 
selves to the single desirable safety property that trains should not collide with 
each other. An AATC system is designed that can control 2 trains, (with addi- 
tional simplifications), and this simple system is proved to be correct. These 
additional steps of our approach arc not done in as much detail as the first 2. 
We ignore track grade and weather conditions throughout this whole chapter. 
We are not concerned with getting trains from station to station in a timely 
manner; only that they travel safely. 

2. Technical approach and method 

In this section we explain the steps of our approach in more detail. Some 
steps which arc performed minimally for the BART case study are only men- 
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tioned briefly here, with references to elsewhere. A high-level overview of our 
approach with its 5 steps is shown in Figure 4.1. 




Figure 4.1. Overview of our Approach. 



The 5 steps of our approach aim to produce a high-quality formal requirements 
document that can be used for further development. The steps of the approach 
— with an emphasis on steps 1 and 2 — are explained in more detail in the 
following sections. 

2.1 Finding the System Boundary 

In this step of our approach we draw up a Use-Case Diagram to document the 
system boundary and the actors that interact directly with the system. Almost 
every UML method begins with drawing up Use-Case Diagrams, and any 
introductory UML book, such as [Qua98], should contain a description of how 
to go about drawing such a diagram. In this section, we name the various parts 
of a Use-Case Diagram and what their meaning is. 

In the case of embedded controllers, we scan the informal requirements docu- 
ment for phrases like “the controller” or “the control system,” and we use those 
phrases to help us determine what is the control system that needs to be designed 
and what is the rest of the system that needs to be controlled. In the Use-Case 
Diagram itself, we denote the system by a dashed box, labelled with the name 
of the system. Around the outside of the box we place stick figures representing 
actors — entities outside the system itself that interact with the system. In most 
UML applications the actors arc roles of persons using an application program 
to interact with the system, but in embedded control the actors can be external 
mechanical devices, sensors, applications, or computer equipment. 

It is important to note that actors portray roles that arc played by identifiable 
entities outside the system, i.e. a single physical entity may be portrayed by 
several actors in the Use-Case Diagram. A single actor may also represent 
several physical devices external to the system ah of which play the same (or 
similar) roles. 
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The goals of the system arc documented in a Use-Case Diagram as well. In 
a banking system, for example, “get account balance” could be a goal, while 
in an embedded vehicle controller, “maintain speed” is a possible goal. These 
goals arc drawn in ovals within the system boundary, so called use cases, and 
attached to the actors (roles) that are concerned with that goal. 

An example Use-Case Diagram is shown in Figure 4.2. 




Figure 4.2. Example Use-Case Diagram. 



2.2 Modelling the Environment 

The second step of our approach, modelling the environment, forms the bulk of 
this entire chapter and section 3.2 in particular. In this section we refer to this 
step as the “modelling step” and give some additional details on how this step 
is performed. 

The modelling step gradually constructs a model of the environment of the 
system under development. The activities arc shown in figure 4.3, below. The 
activities of this step can be divided into constructive activities, where we draw 
new diagrams or change old ones, and validation activities, where we check 
that the diagrams we have made arc sensible with respect to the environment 
we arc modelling. 

Figure 4.3 shows that we begin with structuring, followed by formalizing be- 
havior. After these first 2 constructive steps, we can refine the structure or 
behavior, or validate the diagrams already produced. Validation consists of 3 
fairly independent activities. It is useful to have completed a tracing activity at 
least once before checking the form of the diagrams, and similarly it is useful 
to check the form before checking the properties of the diagrams. Once the 
diagrams stabilize, i.e. the activities of this step do not cause changes in the 
model anymore, the diagrams arc finished and we move on to the next step of 
our approach. 
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Construction ! Validation 




Figure 4.3. Overview of the phases of the Modeling Step. 



Structuring: defining interfaces. The structuring activity adds details 
about the actors in the environment to our diagrams. This activity produces 
Class Diagrams and Message-Sequence Charts. The Message-Sequence 
Charts are actually byproducts, used to document the communications mes- 
sages between the actors and the system. The Message-Sequence Charts 
are re-used in section , since by ordering the messages passed between actors 
and the system they indicate some behavior as well. Once the communication 
paths are clear, we can add details about the various actors in a Class Diagram. 
A Message-Sequence Chart is a diagram that represents an interaction be- 
tween environmental entities and the system under development. An interaction 
is usually directed towards a goal, so the Message-Sequence Chart shows 
how a particular goal can be reached — not necessarily the only way in which 
it can be reached. The Message-Sequence Chart shows only the messages 
exchanged between entities and the system, not the internal actions of each. 
Hence, the Message-Sequence Chart shows a typical sequence of messages 
used to realize some goal. 

A Message-Sequence Chart is headed by one or more boxes denoting in- 
stances of actors and the system(s) they are interacting with. A vertical line 
below each instance is referred to as the life-line of that instance, and exists in 
order to indicate which instance sends a message and which instance receives 
it. Between the life-lines, horizontal arrows indicate messages that are sent. 
Messages may be labelled with a name and possibly with parameters. Reading 
the diagram from top to bottom shows the ordering of messages. 

A example Message-Sequence Chart is shown in Figure 4.4, below. Such an 
Message-Sequence Chart shows that in an interaction with a system called 
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“telco,” there are two actors named “Alice” and “Bob,” in the roles of “caller” 
and “callee .” Alice and Bob first send some messages to the telco system before 
exchanging messages directly. Reading the diagram from top to bottom shows 
that Alice sends the dial message to the telco system before the telco sends ring 
to Bob. There is no way to indicate exact timing in a Message-Sequence 
Chart in standard UML. We will add notes to Message-Sequence Charts 
to indicate timing if it is important. It is important to note that this is only an 
example message exchange and by no means excludes other messages from 
being sent by Alice or Bob during the same time. 

The Message-Sequence Chart is immediately useful in determining some 
of the structure of the system because it shows us which messages (at the very 
least) the various entities in the environment can send and receive, and similarly 
it shows what messages arc sent and received by the system under development. 
These details can be conveniently noted in a Class Diagram. 




Alice: caller 



telco: 

telcoSystem 




dial 


ring 




answer 


hello? 


hi(Bob) 







Figure 4.4. Sample of a Message-Sequence Chart. 

A Class Diagram defines the interfaces involved in the system and the envi- 
ronment. For every actor (role) we draw a class in the Class Diagram. A class 
is represented by a box with three subdivisions. The top division is filled in with 
the class name. In the case of actors, the class name is the name of the actor 
(role) from the Use-Case Diagram, e.g. caller or callee from Figures 4.2 and 
4.4. The next subdivision contains a list of messages that instances of the class 
can receive. These are commonly known as methods. The class callee has a 
method ring, as can be seen in Figure 4.4. The third subdivision in the class box 
holds a list of variables. These variables usually represent properties or quali- 
ties that may vary per instance of the class and that arc visible to the external 
world of that instance. Our example thus far does not contain any variables, but 
the classes caller and callee both can be given a property name, (for instance 
because Alice has a name anyway). We can draw a single Class Diagram for 
all the classes involved in Figures 4.2 and 4.4 as below, in figure 4.5. 
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caller 




callee 




telcoSystem 


hello? 




ring 

hi(aName) 




dial 


name 






answer 






name 











Figure 4.5. Sample of a Class Diagram. 



There arc several things to note in the Class Diagram in F igure 4.5. Class 
telcoSystem has no variables — this is allowed. The method hi in class callee 
has a parameter aName. Every message seen in the Message-Sequence 
Chart in Figure 4.4 is represented, (perhaps in a more general form, since we 
only see hi(Bob) in the Message-Sequence Chart), in the Class Diagram. 
The Class Diagram shows us what kind of things there arc in the system 
and its environment. Together with the Use-Case Diagram, this gives us an 
overview of the structure of the system. The Class Diagram is the important 
result of this phase of the modeling step. The Message-Sequence Charts 
arc byproducts which will be useful in the next phase. 

Finding Behavior: determining state changes. The behavioral phase 
adds details concerning the behavior of each paid of the environment. Every 
class discovered in the structuring phase should have at least one StateChart 
attached to it. Such a StateChart documents exactly how an instance of a class 
reacts to incoming messages and what changes in variable values occur. 

A StateChart consists of a number of states — drawn as rounded rectangles 
— with transitions — arrows — between them. States may be named, in which 
case we write the name inside the state. Each arrow can be labelled with a 
trigger, (the name of a message, possibly with parameters), which means that if 
an instance of the class is in the state at the beginning of the transition arrow and 
receives the trigger message, it changes to the state at the end of the transition. 
Each transition can also be labelled with a guard, (a condition on the values of 
variables in the instance), actions, (assignments to the variables), and messages 
to send. Each of these labels has a typographic convention associated with it, 
for example to distinguish messages sent from the trigger message. Figure 4.6 
shows the conventions associated with states and transitions. 

There is a large body of literature [vdB94] about the exact meaning of State- 
Charts. There arc many pathological cases that can be considered and choices 
to be made. We will avoid pathological cases and draw only “flat” StateCharts 
that arc easy to understand. 

Our interpretation of flat StateChart semantics is as follows: 
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Initial State 




Figure 4.6. Sample of a StateChart. 

■ An empty or absent guard is considered “true.” 

■ Transitions with no trigger arc taken as soon as their guards arc true. 

■ When a message arrives, transitions labelled with it arc taken immedi- 
ately, if their guards arc satisfied. 

■ The actions on a transition arc performed instantaneously, along with the 
sending of messages. 

This semantics ignores cases like non-determinism. The diagrams we draw in 
this chapter arc simple enough that these semantics can be used to interpret 
them. 

A run of a StateChart is a sequence of global states, (i.e. the values of all 
the variables in the StateChart and which of the states of the diagram the 
StateChart is in), and transitions, such that starting in the first global state and 
“following the arrows” indicated by the transitions yields all the global states 
in the sequence. 

We use time in StateCharts in order to be able to formalize the kind of dynamic 
behavior we need to model. The most important extension is that we add the 
notion of time to StateCharts. This already exists in the real-time profile of 
UML; our version is much simpler. We add time so that our StateCharts with 
timed extensions resemble timed automata [LSVW96] or hybrid automata. 
While (an instance of a class with) a StateChart remains in a particular state, 
time passes. This is made explicit within the StateChart by adding timer 
variables to the StateChart, (for completeness’ sake we also add the variables 
to the Class Diagram). Timer variables may be used in guard expressions. 
The only assignments allowed to timer variables assign the value zero (written 
/ timer:=0, this is called a reset). In addition, we can annotate states with 
differential equations such that some variables change their value continuously 
as time passes. These equations are noted as actions within a state, e.g. dv/dt 
= a. The semantics of these extensions arc: 

■ Timer resets on transitions occur instantaneously. 
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■ In a state, time may pass. As time passes, all timers advance uniformly. 
Continuous variables change according to the differential equations (if 
any) in the state. 

■ Time can pass only as long as no transitions become possible. 

The last semantic rule means that we can write guards based on timer values or 
on continuous variables in order to exit a state as soon as the timer or continuous 
value meets the guard condition. Figure 4.7 shows a StateChart using our 
extensions. Because of the timer reset on the transition to the state NotLong 
and the guard on the transition out of that state, we see that we remain in the 
NotLong state for exactly 10 time units (we cannot take the transition out of 
state NotLong until the guard becomes true, and when it is true we must take 
the transition.) 






i timer: =0 


r ~\ 




► 








NotLong 


V J 


•^j[timer= 1 0] 


x J 



Figure 4. 7. Sample of a StateChart with extensions. 

There is much work elsewhere [DJVP03] on formalizing the exact meaning of 
a StateChart in a real-time setting. The real-time UML profile is an official 
attempt at extending StateCharts with useful notation for real-time systems 
and a semantics. Our formalization is rather ad-hoc and does not address any 
of the pathological cases of StateChart construction, but our StateCharts are 
not of the pathological sort. 

After the first 2 construction activities, we have a collection of Class Diagrams 
each with one or more StateCharts associated with it. This gives us both the 
structure of the environment and the behavior of individual parts of it. 

The next 3 validation activities basically check the products of the first two. A 
large number of standard questions is asked, and the answers given can be used 
to modify the diagrams or the informal document. The validation activities can 
be done in any order desired, or in parallel. It is sensible, though, to do them in 
the order listed because of the amount of effort involved, i.e. there is not much 
sense doing a long complicated verification phase if tracing later shows that we 
have forgotten to read a chapter of the informal requirements document. 

Tracing: validating the link between informal and formal. When tracing, 
we ask the question “have we been sufficiently thorough in reading the informal 





100 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



specification?” This is answered — partly — by documenting where all the 
diagram elements come from in the construction phases. Ideally, we tag every 
element of the U M L diagrams with a paragraph or page number referring to the 
informal document. This justifies each diagram element and provides a trace 
of where it came from. 

The other side of thoroughness is completeness. We need to check that every 
paragraph of the informal document has been considered and that that the rel- 
evant information from each paragraph has been used. In order to document 
this, we draw up a list of paragraph numbers and for each we state where it has 
been used or why it is irrelevant. This provides another form of traceability: 
from parts of the informal specification to diagram elements. This is particu- 
larly helpful if changes arc made to the informal document (for example, due 
to questions raised in later phases) and we need to adjust the diagrams in a 
consistent manner. 

Checking Form: validating the diagrams. The activity where we check 
the form of the diagrams asks questions related to the truthfulness of the model 
with respect to itself. These questions can be answered by looking at the 
diagrams without understanding their meaning. 

For models of physical systems, this requires some straightforward checks as 
well as detailed knowledge of the physics of the system involved. For example, 
we need to check that variables that represent some physical quantity arc used 
in a consistent manner, i.e. if x represents the physical position of an object, 
then physics itself constrains in what manner x can change, x can never change 
in a discrete (i.e. non-continuous) manner. 

There arc also simple checks that can be performed on the StateCharts in the 
model that should be performed. Again, these arc questions related to the form 
of the diagrams, and they can be answered almost mechanically. 

■ Does the system react to incoming messages in every state? If not, why? 

■ Are the guards on transitions consistent and complete? 

■ Are all assignments to timer variables really reset assignments? 

We inquire into mathematical truths about the model, both those that arc imme- 
diately apparent as well as those that can be deduced by performing calculations 
on it. Typical tools used for these calculations arc model checkers or a proof 
assistants. We ask questions like “can the automata ever reach this state? Is 
there a path from this one state to that one?” 

Checking the form of the diagrams through model-checking or theorem-proving 
can be very labor-intensive, particularly when many questions need to be an- 
swered — and it is often not entirely clear what questions should be asked. 
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Deciding what the “standard” properties to check arc requires some experience 
in validation. 

Checking Properties: validating on a higher level. This activity asks us to 
judge whether the model is “good enough”. It requires a thorough understanding 
of both the model and the system being modelled. Thus far we have checked 
that the formal model is consistent with the informal document and that it is 
internally consistent. In this phase we ask whether the model is consistent with 
the actual environment described in the informal document. 

The basic questions to ask in this section arc: “The model predicts such-and- 
such. Does this happen in the real world as well?” and the converse “We observe 
such-and-such in the real world environment. Does the same thing happen in 
the model?” These arc fundamental questions and there arc no hard-and-fast 
rules how to answer them. 

The best thing to do is to confer with a domain expert again about the model 
of the environment; this time, instead of working from the informal document 
towards the formal model, work from the formal model towards the real world. 
For the purpose of answering these questions, simulation techniques can be 
used. A simulation allows you to see how the model of the system behaves. 
Most model checkers include simulation tools as well. 

Post-Validation. Once we have finished this step, (by constructing and 
validating a module of the environment of the system in UML diagrams), of our 
approach, we have a Use-Case Diagram stating the high-level goals of the 
system to be built and how those goals relate to various parts of the environment. 
We also have a Class Diagram that formalizes the structure of the entities 
in the system and the environment, and for each class we have one or more 
StateCharts that formalizes the behavior of instances of the class. 

The goals diagram can be used in the next step of our approach, in section 2.3, 
while the structure diagrams can be used for high-level design, as mentioned 
very briefly in section 2.4. 

2.3 Formalizing Properties 

The formalization of the properties of the system is not a topic in this chapter. 
For every high-level goal in the Use-Case Diagram, we can write a mathe- 
matical formula based on variables from actor instances and the system itself. 
In the present chapter, this is straightforward, since we have chosen only a 
very limited property to verify. See [dGHOO] for a more in-depth look at the 
formalization of properties for the system. 
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2.4 High-Level Design 

High-level design needs not be considered paid of the requirements improvement 
approach. 

The high-level design of a system consists of a refinement of the behavior 
diagrams already created. The design serves as an additional check that the 
behavior requirements we have found can be realized. 

In this chapter, we will not refine the behavior diagrams, but use them directly for 
the final step, (also not strictly paid of our requirements improvement approach), 
high-level verification. 

2.5 High-Level Verification 

High-Level verification needs not be considered paid of the requirements im- 
provement approach. 

Our verification consists of translating all the diagrams into the language of a 
theorem-prover and proving some basic safety properties such as that two trains 
cannot crash into each other. 

3. Applying our approach to the case study 

As a demonstration of our method and its usefulness in finding errors in a 
requirements document, we will apply it to the BART/aatc case study. The 
case as a whole is too complicated to be done comfortably here, but we will 
select a relevant and representative paid of the case study to do. In section 1.4 
we chose to model only the trains of the BART system. 

3.1 Step 1: Finding the System Boundary 

Scanning the informal requirements document leads us to skip paragraphs 
Pair 1-9 because they provide only background information and set the stage 
for this case study. Paragraph Pair 10 is the first paragraph explaining techni- 
cal details of the BART system. It names 3 parts: the station computer, the 
communications network, and the train(s) in the system. The same paragraph 
mentions that the train has both brakes and motors. This is useful structural 
information, since it tells us that the trains arc not paid of the system proper. 
The AATC system’s environment is made up of the trains that it controls. From 
a UML point of view, this means that the trains are actors — things outside of 
the system itself that cooperate with the system to achieve some goal. This is 
a fact we can find in Pair 5, Pair 10 and Pair 12. The aatc’s high-level goal is 
to provide safe and comfortable passenger train service in the Bay Area. We 
can break this high-level goal down into a number of subgoals which can be 
represented by UML Use-Case Diagram. This is shown in Figure 4.8. The 
goals come from Pair 14. 
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AATC System 




Figure 4.8. Use-case overview; Par. 10. Par. 14, Par. 50. 

Par. 12 suggests that the communications network is perfect, i.e. messages sent 
through the network arrive in order, with no delay, and no messages arc ever lost. 
If the communications network had interesting properties, (lossy, disordered 
communications that might introduce real safety problems), we would choose 
to model it separately. Instead, we will allow the environment to communicate 
directly with the AATC system as if there is no separate communications system 
present at all. This simplifies the model somewhat. Similarly, we could model 
the brakes and the motors separately, but it seems to add a lot of complexity 
without adding interesting behavior. 

This high-level view of the system contains too many goals to be realizable 
and checkable, while at the same time the level of detail in the environment is 
too low. Reading Par. 10, Par. 11, Par. 16 shows that the environment of the 
AATC system, while physically contained completely within a train “consist,” 
logically has two parts: the physical paid of the train (a large piece of metal 
that is constrained by the laws of physics) and a train controller (a computer 
inside the physical train) that manipulates the brakes and motors of the train in 
response to commands sent by the AATC system. We will ignore the goals of 
the system except “never collide with leading train,” so that we have only one 
property to verify later. These changes arc shown in Figure 4.9. 

We use a Use-Case Diagram such as 4.9 to structure the rest of our diagrams. 
This particular diagram shows us 2 actors and the system itself — so our Class 
Diagram will contain 3 classes — and also 3 points of interaction between 
entities. There is 1 interface between the physical train and the AATC, and 
1 between the AATC and the train’s control system. In addition, there is the 
interface between the train controller and the train itself. 
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Figure 4.9. UcD simplified; Par. 10, Par. 11, Par. 16. The black diamond on the connection 
between the Train Controller and the Train indicates that the Train Controller is aggregated — 
a physical part of — the train.. 



3.2 Step 2: Model the Environment 

Our goals for this step of are to produce a Class Diagram for the system as a 
whole, and StateCharts for each class. We will run through the 5 activities of 
this step in the following sections. 

Structuring. This activity is concerned with drawing a Class Diagram 
for the entire system. In order to detail the interfaces involved, we draw some 
Message-Sequence Charts as well. This entire section is based on Par. 15- 
17. The section contains some considerations about the style of interface used 
between different parts of the system as well. The communications between 
the AATC system and the train go through the AATC communications system, 
which Par. 12 points out is assumed to be perfect. Other communications do 
not go through the AATC communications system, and thus the style of those 
interfaces needs to be considered separately. 

Par. 1 5 mentions some of the messages that arc sent through the communications 
network of the BART system: trains send sensor data ( Par. 16) and the stations 
send speed and acceleration commands ( Par. 17). 

The interface between the Train actor and the AATC system is related to the status 
reports mentioned in Par. 16: the train sends speed and ranging information 
to the AATC, along with a time-stamp. The commands arc sent back to the 
train controller since those commands need to be interpreted as motor or brake 
commands before they can affect the train itself. For the interfaces between the 
actors and the AATC system, a message passing interface makes sense, since 
real messages arc being sent over a radio link. There is no other communication 
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between the train (or its controller) and the AATC system. Figure 4.10 shows 
the messages passed in the system. 




Figure 4.10. Messages sent between system and environment. 

The interface between the actors — between the physical train and the train 
controller — is not suited to message passing. The train controller continuously 
influences the train by varying the acceleration imparted on the train by the 
brakes and motors. For this interface, we use some shared variables which arc 
set by the train controller and read by the physical train. 

Identifying these messages allow us to draw a Class Diagram for the aatc 
system's environment. Note that this is a model of the environment of the 
AATC system and that a real train (large, yellow and very very heavy) does not 
necessarily have a message status that it can send. The Class Diagram can be 
used to collect information contained implicitly in other diagrams, and refers 
to other diagrams for clarification. Figure 4. 1 1 shows a first attempt at a Class 
Diagram that shows all the actors, the system and their interfaces. 




AATC 

status(MOTT,x,v) 



Figure 4.11. Class Diagram for actors. 



Finding Behavior. This section adds StateCharts to the classes found 
in the previous section in Figure 4.11. It turns out that some classes benefit 
from using more than one StateChart to describe their behavior because the 
individual StateCharts arc simpler that way. The first paid of this section is 
concerned with the physical behavior of the Train class. The second paid shows 
how messages to the Train Controller class are handled. 
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Common sense tells us that the train has a certain position and speed. These 
arc the real physical attributes of the train, and they change continuously. We 
use our extensions to the StateChart notation to denote these continuously 
variable values. We use x for the train’s position and v for its speed. In addition, 
the maximal jerk rate that the motors can exert influences the acceleration of 
the train. We will write j for the jerk rate. The differential equations arc 
straightforward. This leads to an initial StateChart for the train physics as 
shown in Figure 4.12. 



V- 

/ dx/dt = v 
/ dv/dt = a 
/ da/dt = j 



Figure 4.12. Train Physics. 

Looking at Par. 16, we see that the station receives sensor data from the trains 
every half second. We will interpret this to mean that the train sends the data 
every half second and that the station then receives it. This means we need 
to add a timer and a transition such that every half second the train sends its 
position and speed to the AATC. We will call this timer ta. This leads us to add a 
transition from the lone state in Figure 4. 12 to itself. We choose milliseconds as 
the unit of time, so the guard on this new transition can be written as [ta=500]. 
The transition is taken when the timer value reaches 500; as the transition is 
taken we reset the timer to 0. As mentioned in section 2.2, we allow time to 
advance only as long as no guards become true. Therefore, this transition must 
be taken every 500ms. 

Looking at the next paragraph of the informal specification. Par. 17, we see that 
the status message also carries a time-stamp mott. This means that the train 
must have a local clock in order to report the time. We will call the timer that 
records the local time in the train twc, for Train Wall Clock. The status message 
that is sent to the AATC system carries the position and speed as well as the 
value of the twc timer when the message is sent. Adding the transition to the 
StateChart for the Train class yields Figure 4.13. 

Handling command messages. Under normal circumstances, the train 
regularly receives a command message from the AATC carrying a desired speed 
and acceleration. Par. 16-17 tell us that each message carries a time-stamp: the 
time stamp of the last status report received from the train by the AATC system. 
The values received from the AATC need to be stored so that the train controller 
can act upon them. The state regular operation in Figure 4.15 captures this 
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V-Q 



[ta=500] / ta:=0 A AATC.status(twc,x,v) 



/ dx/dt = v 
/ dv/dt = a 
/da/dt = j 



Figure 4.13. Train behavior. 

behavior. It has a transition to itself that is triggered by the receipt of a new 
command message. We use the variables pmot (previous message origination 
time) and rv and ra (requested speed and acceleration, respectively) to store 
these incoming values. 

Variables should be given some initial value. Let us assume that a train is in 
normal operations mode when first switched on, and that all 3 storage variables 
arc initialized to 0. This is a safe starting state, since the train then begins with 
a requested speed of 0, i.e. it should remain at rest. We attach the initializations 
to the initial transition. This is shown in Figure 4. 14. 



/ pmot:=0 cmd(LMOT,i 




r, ma) / pmot:=LMOT, rv:=mv, ra:=ma 



Figure 4. 14. Train Controller behavior related to receiving command messages. 

If no command arrives, (i.e. the station controller fails to send any commands 
for some time), then eventually the train should enter failsafe stop mode, as 
mentioned in Par. 18. It does this when the last command received — which 
carries the time-stamp of the status report it is based on — is more than 2 
seconds old. The 2 seconds are measured between the value of the twc timer 
and the pmot value. As shown in Figure 4.14, pmot holds the time-stamp of the 
last command. The guard, then, for the failsafe mode is [twc-pmot>2000]. 
When the train enters failsafe stop mode, it tries to begin braking. All this is 
shown in Figure 4.15. 

Controlling Brakes and Motors. The train controller handles configuring 
both the motors and the brakes. We assume 2 functions motorDisengaged() 
and brakeDisengaged() that state when the brakes or motor are disengaged. 






108 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



/ pmot:=0 cmd(LMOT,mv,ma) / pmot:=LMOT, rv:=mv, ra:=ma 




Figure 4.15. Train Controller behavior with timeout; Par. 17. Par. 18. Par. 27. 



These are necessary because the informal requirements document does not 
state exactly how long it takes to disengage the brakes and motors, nor does 
it state under what conditions the motors and brakes can be considered to be 
disengaged. A reasonable guess for the motors is “when the acceleration and 
jerk rate arc both 0, the motors arc disengaged,” but we do not need an exact 
definition here. Once the motors and brakes arc disengaged, some time is spent 
reconfiguring the propulsion unit for braking or acceleration. During this mode 
change, timer tc is used to track the delay. The delay is stated to be 1000ms 
in Par. 35, Par. 36. Diagram 4.16 shows our StateChart for controlling the 
motors and brakes. 




Figure 4.16. 



Train Controller behavior controlling motors and brakes; Par. 35, Par. 36. 
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This diagram is still fairly “high-level” since we have omitted details of exactly 
how the the jerk rate is set when the motor or brakes arc activated. We have 
used I'u n c t i o n s fh 1 , Jb 2 , fa 1 and /n'2 as place-holders for the real behavior of the 
brakes and motors. 

Intermission: Updating the Class Diagram. Each of the StateCharts 

we have drawn states (paid of) the behavior of one of the classes from our Class 
Diagram in Figure 4.1 1. Since the StateCharts have introduced variables and 
the passage of time introduces timers, we will need to add these variables and 
timers to the Class Diagram. 

The train controller and the train itself both have timers, twe, ta and tc. The train 
itself variables x, v, the acceleration a and the jerk rate j. All these variables 
are added to the Train class from Class Diagram 4.11. This leads to a new 
and expanded Class Diagram, which is shown in Figure 4.17. 




Figure 4.17. Class diagram showing all variables. 



Tracing. This section shows the operation of the tracing phase of our 
method. As stated in the method overview in section 2.2, this is a largely 
administrative phase. Readers interested in the results of this phase without the 
tedious justification can skip to “Issues Raised,” on page 110. 

Sections 1 through 3 of the informal specification. Par. 1-9, arc general intro- 
ductory paragraphs and contain no important information for our view of the 
environment of the AATC system. Section 4 is heavily used: Par. 10-15 were 
used to create diagram 4.8. Par. 16-18 arc used in diagrams 4.13 and 4.15. The 
remainder of section 4, Par. 19-22, is concerned with the physical division of 
the AATC system and not relevant for our description of the environment. 
Section 5 of the informal document has not been used much: Par. 23 describes 
the information that the AATC has to work with, but this just repeats Par. 16. 
Par. 24 defines the high-level goals present in our Use-Case Diagram 4.9, 
Par. 25 and Par. 26 describe gate information which is uninteresting for our 
view of the system. Finally, Par. 27 reiterates Par. 17 with considerably more 
detail. Par. 28 is a one-line filler paragraph. 
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Section 6 contains some details not yet taken into account: Par. 29 describes 
details of the function fal which is used in diagram 4.16. It is stated in Par. 29 
that the train can coast in propulsion mode, so perhaps there should be no 
“Disengaged” state in the diagram. Par. 30 states that the train will initiate 
braking to prevent speeding, which is reflected in the guard rv < v on the 
transition from the “Acceleration Mode” state to “Disengaging Motor.” This 
transition can be taken in response to a command which changes the requested 
speed of the train, or in response to the train reaching too great a speed (for 
example, as a result of rolling down a hill). We assume that the train will also 
initiate acceleration to achieve the requested speed whenever it is in braking 
mode and going too slow. Par. 3 1 states that trains can enter open- loop braking 
and brake at 3mphps; the transition to failsafe mode in diagram 4.15 reflects 
that. It is unclear, though, whether the mode-change delay applies to open- 
loop braking as well, and whether it is possible to exit from open-loop braking 
mode without a system reset. Par. 32 and Par. 33 remind us that rain is an 
important factor in reducing brake rates, but as we have chosen to ignore the 
weather, we ignore this paragraph as well. Par. 34 repeats information already 
available in Par. 27. Par. 35 and Par. 36 define the mode-change delay, which 
is incorporated into diagram 4.16 by including the mode-change states and 
the motorDisengaged() and brakeDisengaged() functions. Finally, Par. 37 
reminds us that we may idealize the physics of the trains to some extent. 

The section on the worst-case stopping profile of the train is not relevant for 
our description of the actual behavior of the train, but is relevant for the design 
of the AATC system itself. This makes Par. 38-49 unimportant for our current 
formalization. Similarly, all of sections 8 (Par. 50-55) and 9 (Par. 56-65) arc 
concerned with qualitative and quantitative aspects of the commands to be sent 
to the trains, and arc therefore not relevant now. 

The questions-and-answers section is relevant for the behavior of the trains, 
since Par. 66 states that trains can never go backwards (even if, for example, 
they are in coast-mode while resting on an up-grade of 4%). This obviously 
means that the differential equations used to describe the train in diagram 4.15 
arc not entirely accurate: a negative v is impossible. While Par. 67-70 arc 
irrelevant. Par. 71 shows that the state “Disengaged” in diagram 4.16 does not 
exist in the train itself. This means some minor changes in the diagram arc 
needed. Par. 72-78 again arc not concerned with the specific behavior of the 
trains, and therefore unimportant for the formalization of the environment of 
the AATC system. 

Issues Raised. This concludes our re-reading of the informal specification, 
and yields five changes that need to be made to the diagrams in order to reflect 
new knowledge: 
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1 The train’s behavior while accelerating is more complex than documented 
in the diagram. This issue will be resolved in section 4.17 

2 There disengaged state in Figure 4.16 should not be there. Except 
during mode changes, the propulsion unit is always configured for either 
braking or acceleration. It is possible to coast in acceleration mode, 
though. We will repair this diagram in section 4.17 as well. 

3 The transition out of braking mode is assumed to be taken also when the 
train brakes to below the requested speed. It should be documented as 
such. This too is resolved in section 4.17. 

4 Open-loop braking may need to be treated differently from normal brak- 
ing. This issue will not be resolved. 

5 The differential equations describing the train’s physics need to be ex- 
tended to handle the “no backwards” behavior. This will not be resolved 
in our UML diagrams. 

Other considerations not directly related to the tracing phase, but which arc 
raised by re-reading the informal document, are: 

6 The physics in Figure 4.12 is grossly simplified because it does not even 
take the track grade into account. We could extend the differential equa- 
tions to account for track grade fairly easily. 

7 The behavior of the status mechanism, from Par. 16 seems straightfor- 
ward and the StateChart certainly reflects what the train should be doing. 
However, the paragraph in question opens with “The AATC system op- 
erates on 1/2-second cycles.” Our assumption that this means that the 
trains send sensor data every half-second may not be accurate at all. Per- 
haps the AATC system sends new commands every half-second, based on 
whatever information it has about trains. Since this is not a question we 
can resolve ourselves — since we do not know intimate details about the 
system — we will have to ask someone who does know how the trains 
behave. 

Intermission: Updating the StateCharts. Now that we have asked a 
number of questions and answered most, we can re-do the UML diagrams 
describing the train’s behavior. We do the re-drawing before verifying properties 
of the model because there is no sense in putting the effort of mathematical 
verification into a model which is known to be inaccurate. 

The physical behavior of the train has not changed, so Figure 4.13 remains 
unchanged. Figure 4. 15 is modified by adding a transition back to the “Regular 
Operation” state, yielding Figure 4.18, below. 
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/ pmot:=0 cmd(LMOT,mv,ma) / pmot:=LMOT, rv:=mv, ra:=ma 




Figure 4.18. Train Controller (messages) behavior. 

Finally, the diagram for the train controller controlling the motors and brakes is 
considerably revised. There are additional states dealing with the specialized 
acceleration behavior of the train, and the “Disengaged” state has disappeared. 
The function fal has been split into 3 parts, fin 1, fml and j)n‘.\ depending on 
the state of the train, making the different acceleration profiles mentioned in 
Par. 29 and Par. 30. 

The guards PD, PN and PC arc defined as: 

PD = v < rv — 7 mph 

PN = rv — 7 mph < v < rv — 2m ph 
PC = rv — 2m ph < v < rv 

Checking Form. This subsection examines the diagrams that have been 
drawn so far. The aim of this section is to ask questions about the form of the 
diagrams. These questions translate into questions about the informal document 
and the behavior of the trains it describes, but arc based entirely on elements 
of the diagrams. The diagrams we have a surely not a complete picture of how 
the BART trains behave. 

Standard questions that should be asked about StateCharts are: 

■ Does the system respond to messages in every state? 

The train does respond to cmd messages as long as the train controller 
(messages) is in state Regular Operation, but in Failsafe Mode no 
additional messages arc accepted. None of the other StateCharts reacts 
to external messages at all. This means that the train, once it enters 
failsafe mode, cannot be restarted by commands from the AATC system. 

We asked the developers of the case study to comment on this issue, and it 
turns out that trains can leave failsafe stopping mode on receipt of a new 
command message, and that the AATC system can even make deliberate 
use of the failsafe stop mode to manage trains. This means that we need 
an additional transition back to Regular Operation. 
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Figure 4.19. Train Controller (brakes and motor) behavior. 

Since there arc no other messages that can be sent to the train, this phase 
of the analysis is short. 

■ Is the timing of the transitions correct? 

We have assumed that transitions take no time, and have modelled the 
mode-change delay when switching from braking mode to propulsion 
mode (or vice-versa) by including a delay state with an explicitly enforced 
delay of 1000ms. If we had chosen for a model in which transitions take 
time, we would have to take this into account in the delay states. 

■ Are the guards of all states consistent and complete? 

If a state has transitions with guards on them, then the guards should 
either be disjunct or the informal specification should explicitly allow 
the choice between the non-disjunct transitions. In addition, we need to 
ask if the transitions out of a state arc indeed all of the ways to leave 
the state. The easiest way of checking this is to examine every state in 
the system and consider the transitions there. Few of the states in our 
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diagrams even have more than one transition out of them. That makes 
consistency easy to check. The guards on transitions within the set of 
drive states in Figure 4.19 arc obviously complete. 

■ Are all needed transitions included in the diagrams? 

This is the most subjective of the questions asked in this section. It is 
related to the first question, though, in the sense that it asks about the 
system’s response to changes in its internal variables, timeouts, etc. In 
particular, we need to check that no timeouts arc missed, and that timers 
are reset when appropriate. 

Another thing to check for that may indicate a problem is “cascading 
transitions” where a sequence of states and transitions exists where the 
guards on the transitions may be simultaneously true, leading to multiple 
instantaneous transitions (i.e. the first transition is taken and in the new 
state another guard is true so that transition is also immediately taken, 
etc.). This can indicate a problem, but may also be sound design. It is 
important to the quality of the final requirements document to make this 
explicit. 

An example of cascading transitions can be seen in the StateChart for 
the class Train Controller, Figure 4.19. The controller remains in the 
state Mode Change to Brake for a whole second. During this time, 
the other StateChart for the controller, in Figure 4.18 could change 
the values of rv and ra in response to a command message. At the 
end of the one second sojourn in the Mode Change to Brake state, 
we have a cascade of transitions: from Mode Change to Brake to 
Brake Mode to Disengaging Brakes possibly continuing on to Mode 
Change to Motor. This shows that something may be amiss. We may 
need an additional transition from Mode Change to Brake immediately 
to Mode Change to Motor in order to abort a mode change. 

Another example of cascading transitions can be seen when leaving the 
Drive Slow state. The exit transition goes to an anonymous intermediate 
state and from there to one of the other drive states or to the disengaging 
brakes state. This is intentional, though, to avoid a tangle of transitions 
from each drive state to all the others. 

Checking Meaning. Checking the meaning of the diagrams is a mathemat- 
ical activity. Based on the questions and answers of the checking form phase, 
we might try to prove various properties of the model of the environment: for 
example, that trains can never go backwards, or that some particular state of the 
train controller is never reached. In this section we will verify a property of the 
model of the environment, not mathematically but with sufficient rigor as to be 
convincing. 
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Maximum speed. One goal of the system originally pictured in Figure 4.8 
is that the train should never exceed the posted civil speed limit (see Par. 14, 
Par. 76). This is not a property we can check now. However, we can investigate 
a weaker property and so try to verify that the model is accurate. 

We ask the question: can the train ever exceed the maximum civil speed limit 
of 80 mph? The maximum speed the AATC can send is 80 mph as well. 
Suppose the train is changing from braking mode to acceleration mode in re- 
sponse to the AATC sending a command message for 80 mph. Then the train 
is in state Disengaging brakes, labelled A in Figure 4.20 below. After some 
time, the controller changes to the Mode Change to Motor state, and assum- 
ing the AATC keeps sending the 80 mph command, after another second the 
controller takes 2 more transitions to state Drive Fast, labelled B. Again, if the 
AATC keeps sending the command to travel 80 mph, the train will eventual near 
that speed and take 2 transitions into Drive Slow, labelled C. 




Figure 4.20. Checking Behavior. 

In the drive slow state we see that the acceleration due to the motors is tuned 
so that it reaches 0 mphps when the train reaches a speed 2 mph below the 
requested speed, (i.e. at 78 mph, the train stops accelerating). According to our 
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simple model of the train’s physics (Figure 4. 13), the train maintains this speed 
and acceleration indefinitely. Therefore in our model we have verified that the 
train never can exceed the maximum civil speed of 80 mph. 

In the real world, where wind and rain and track grade play a role, this reasoning 
does not hold. If we involve both wind resistance and the track grade in the 
train’s physics (something we completely neglect in Figure 4.13), then it is 
obvious that on a 4% downgrade with a 20 mph tail wind, (certainly possible 
conditions within the BART system area), that the train receives an additional 
acceleration of 0.88 mphps due to the grade (see Par. 54) and some deceleration 
due to wind resistance. If the acceleration due to the grade is greater than the 
deceleration due to wind resistance, the train will accelerate past 78 mph. In 
this case, the train controller leaves the Drive Slow and enters the Drive Stop 
state, labelled D. If the incline is long enough, after 2.3 seconds the train will 
reach 80 mph. When the train reaches 80 mph, 2 more transitions arc taken 
and the train reconfigures for braking. This takes one second, during which 
the train has reached a maximum speed of 80.88 mph (label E). This shows 
that we should begin braking earlier, perhaps disposing of the Drive Stop state 
entirely. 

Although this phase suggests that we could make a few changes to the diagrams, 
we will not do so and keep the diagrams from section unchanged. 

4. Designing a Controller 

In this section, we begin the design of a controller (i.e. the design of the AATC 
system itself) by constructing a StateChart that sends commands to a trailing 
train based on the information the AATC has on the trailing and the leading 
train. We ignore things like track grade and rolling resistance in the design of 
the controller, since we have ignored them in the description of the environment 
as well. 

We see that we need to design a control system that controls one train while 
also listening to status reports from another, as illustrated in Figure 4.21. 

Our AATC system therefore must react to incoming status messages and (pos- 
sibly) send command messages. Let us assume that we have a state “normal 
operation” to deal with all these messages. Then the basic structure of our 
AATC system is as illustrated in Figure 4.22. 

This diagram leaves 2 things unclear: how often is a command sent, and what is 
done with the incoming status messages? In particular, no distinction is made 
in our diagram between status messages coming from the leading train and 
from the following train. The informal specification suggests that commands 
are sent every half second (in Par. 16) and also that at most one command can 
be verified by the AATC and sent per half-second (in Par. 20). We will ignore 
these 2 timing issues and and allow commands to be sent as often or as seldom 
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AATC 



Leading 
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Note that command 
messages may be 
. sent more often 
than once every 
half second. 



Figure 4.21. Communications between trains and the AATC. 



status(LMOT,x,v) 




[newSpeed] A cmd(LMOT,rv,ra) 



Figure 4.22. Very rough design for the AATC. 

as desired, by using a fake guard [newSpeed]. We need a guard, since empty 
guards are considered true and will cause the transition to be taken immediately. 
We will annotate each message in the StateChart with the name of the object 
it is sent to or received from. In addition, we will add a number of variables to 
the AATC class to store information received from the trains: 

x\ . X‘2 The position report sent by the following train (x\) and the leading train 

te)- 

vi The last reported speed for the following train. 







118 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



lmot\ The mott sent by the trailing train with its last status report. 
Figure 4.23 shows the StateChart with additional details. 



T2.status(-,x,-) / x2:=x Tl.status(MOTT,x,v) 




[newSpeed] A Tl.cmd(LMOT,rv,ra) 



Figure 4.23. Design for the AATC. 

This StateChart shows us more of how the system should react to the trains. 
What it does not do is indicate how often the commands are sent to the trailing 
train. In spite of Par. 16 and Par. 19 we have chosen not to place a lower bound 
on the time between two command messages to the train. There is no upper 
bound either, since the control system can choose not to send any command to 
a train and thus let the train enter failsafe stop mode (this is not stated in the 
informal specification but Victor Winter, author of the case study, assures us 
this is so). 

The diagram also does not state what speed and acceleration values arc sent 
to the train. We cannot just send any values as speed and acceleration, since 
that may violate the safety principles. In the end, we need to check that in the 
complete system as shown in Figure 4.21, the following holds: 

T\.x + wcsd(T\.v) < T 2 .X 

i.e. wherever 7j (the trailing train) is, it can always stop before wherever 74 is 
— even if 74 comes to a catastrophic halt. 

Our challenge now is to find out what conditions to enforce on the speed and 
acceleration values sent to the trains so that the safety conditions arc met. 
Obviously there is a safe speed and acceleration command possible: order the 
train to stop (speed Omph, maximal deceleration of -1.5mphps). With the train 
standing still, no unsafe situation can be created. Although this does not satisfy 
the system goals other than “avoid collision”, we are not concerned with them 
here, see Figure 4.9. 

In essence, for every distance between trains 1 and 2, (and if we were modelling 
more accurately, the track conditions need to be taken into account too), we need 
to calculate the maximum allowable speed and ensure that the speed sent is less 
than that. We will denote this calculation in the diagram by SafetyCheck(v,a) 
yielding, finally. Figure 4.24. 
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T2.status(-,x,-) / x2:=x 
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T1 ,status(MOTT,x,v) 

/LMOT:=MOTT 

/xl:=x 

/vl:=v 



[newSpeed AND SafetyCheck(xl,vl,x2,rv,ra)] 
A Tl.cmd(LMOT,rv,ra) 



Figure 4.24. Design for the AATC with safety features. 

From now on, we will not modify the diagram anymore but concentrate instead 
on the details of the calculation SafetyCheck(v,a). 

How to find a good definition for SafetyCheck(v,a) is beyond the scope of this 
chapter. The following crudely defined formula is a starting point, and in later 
sections we provide a more detailed formula that can be used with a simplified 
model of the trains’ behavior. 

SafetyCheck(v, a) = v < 80mph A T\.x + dtbt(v, a) + wcsdfimsbt) < T 2 .X 



In the formula, dtbt stands for Distance Travelled Before Timeout, i.e. the 
distance travelled by the train between its last status report and the moment it 
enters failsafe mode, wcsd of course stands for Worst Case Stopping Distance, 
which is a function of the Maximum Speed reached Before Timeout. 

4.1 Formalizing the UML Diagrams 

Just as in section 4.19, we want to be able to verify properties of the AATC 
we have designed. In 4.19 we had but 3 StateCharts to keep track of: The 
Train, and 2 for the Train Controller. One of the 2 StateCharts for the Train 
Controller is trivial, so could be ignored in the analysis. Now we have at least 
7 to contend with, for 2 trains and the AATC controller. The number of possible 
sequences of actions and delays has grown enormously and we do not want 
to keep track of them by hand. In section we discussed various tools for 
verification problems. Here, model checking seems infeasible due to the size 
of the state space, the differential equations, and the lack of precision so far in 
defining the safetyCheck() function and the differential equations in the drive 
states of the Train Controller. This leaves theorem-proving as the method of 
choice for attacking verification problems related to our AATC design. 

Our preferred tool is PVS, a theorem prover developed at SRI. It has a rich 
language and a fairly easy-to-read syntax. We will present a little of the PVS 
syntax in this section, sufficient to formalize the diagrams we have. 
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While in theory a theorem prover can do any sort of mathematics — with human 
intervention and assistance — we quickly realized that PVS is extremely limited 
in its ability to manipulate algebraic expressions, and simplifying an expression 
such as the definition of the WCSD as in the informal document is an exercise 
in frustration. There is ongoing work to make theorem provers in general 
and PVS in particular more effective in algebraic manipulation, but we chose to 
simplify our model instead to reduce the complexity of the algebraic expressions 
encountered. Our simplifications are: 

■ Elimination of the jerk rate. We use only one fixed acceleration a, which 
the train can use in accelerating or braking. The train can coast as well, 
with an acceleration of 0. 

■ Elimination of the mode change delays. The train can switch from ac- 
celerating to full braking (both at rate a) in an instant. 

■ The failsafe timeout is 2 seconds from the last received command instead 
of 2 seconds from the time-stamp of that command. 

■ Elimination of the details of the movement of the leading train. We 
assume that it always moves forward and do not worry about the manner 
in which it does so. 

■ Elimination of the fine-tuning of the train’s approach to the target speed. 
Instead of using the 3 drive states with different jerk-rate profiles, we let 
the train accelerate at full speed to the requested speed and then switch 
instantaneously to coast mode. 

■ Both trains send their status report at the same time, not at different times 
as illustrated in Figure 4.21. 

The first two simplifications mean that the train in the simplified model reacts 
more quickly to commands and timeouts than a real train. We must therefore 
be very careful about extrapolating results based on this model to the more 
complex model initially arrived at. The third simplification means that the 
simplified trains enter failsafe stop mode later than a real train would. In 
this case the simplification is conservative with respect to safety. The fourth 
simplification is hardly a simplification at all. As far as our limited view of the 
AATC is concerned, the behavior of the front train may as well be random, and 
we need to control the back train such that it cannot crash into the unpredictable 
front train. The last of the simplifications is intended to reduce the number of 
states we need to consider. We do not believe that it has any impact on the 
safety of the system. 

After these simplifications we could reconstruct StateCharts to represent them, 
but we feel this would be a waste of time because what we want is a represen- 
tation in PVS of the simplified behavior. Therefore we proceed directly to that 
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representation. We represent StateCharts in PVS as timed hybrid automata. 
Instead of representing each StateChart individually in PVS, we represent the 
product automaton, i.e. one big automaton for the entire system and its envi- 
ronment. In many cases this leads to a tremendous state explosion, but, thanks 
to the simplifications listed above, here it does not and the product automaton 
remains tractable. 
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Figure 4.25. Three StateCharts describe 
the behavior of a single train. They should 
be recognizable from earlier sections. 



Figure 4.26. On the right, each of the two 
trains is composed of the three StateCharts 
on the left, while the AATC system is described 
by the single StateChart from 4.24. 



We use a single global state that holds the values of all the variables and timers 
in the system. These arc the position and speed of the trailing train, a and v. 
Our simplifications remove the need for the trailing train’s acceleration or jerk 
rate. The leading train is represented only by its position. The timers tc and twc 
arc still needed for determining the period for sending status messages and for 
determining the time of day. Since we have abstracted away the mode-change 
delay, the timer ta is not needed. Due to our simplification of the failsafe timeout, 
we do not need the variable pmot either. This leaves us with the following bit 
of pvs code, which defines a record type holding all of the variables relevant 
to the AATC system and two trains. There is no mention of the states found in 
the StateCharts, because the individual states arc not relevant any more after 
all of our simplifications. The variable names have changed a little from the 
StateCharts, but should be self-evident. 



States : TYPE = [# 
posTl : Position, 
speedTl : SpeedLimit, 
reqspTl : SpeedLimit, 
posT2 : Position, 
failsafeTl : bool, 



"/, models actual position of T1 
"/o current speed of T1 
"/o requested speed for T1 
"/, actual position of T2 
"/o Is T1 in failsafe mode? 
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Runs of the B art/a atc system consist of sequences of the States record and 
actions. The action must be “legal” with respect to the StateCharts used as 
input for this formalization. The actions may be: 

■ Time passes, which advances the timers and updates the continuous vari- 
ables, but does nothing else. In the PVS formalization, this action is 
written Delay (d) where d represents the number of milliseconds that 
pass. 

■ The AATC sends a new command to the trailing train, which sets the rv 
variable and resets the failsafe timeout timer. This is written NewSpeed ( v) . 

■ The failsafe timer expires. This causes an immediate change to fail- 
safe brake mode and sets the requested speed to zero. This is written 
FailStop. 

■ The status timer expires. A message is sent to the AATC which updates 
the variables recording the position and speed of the trailing train. The 
action Status represents this transition. 

These four different steps need to be formalized as well. For each step we need 
to write out under which conditions it can take place (for example, the status 
timer expires when the timer c reaches 500ms) and what the effect of the step 
is, (i.e. what effects the transitions has and how to code the new state). 

The status effect can only occur when the timer c has the right value. This is 
written as 

StatusGuard(s : States) : bool = s'c = P 

Here s stands for the current state of the system, and the notation s ‘ c selects a 
field in the record that represents the state. The effect of the transition is that the 
AATC system receives the position and speed of both trains and records them. 
The new state is therefore an update of the old state with the AATC variables 
updated. This appeal's in PVS as shown in Figure 4.27. We can see that the 
variables are set and the timer reset with this expression. 

Similar expressions are written for the remaining transitions for failsafe stop 
and receiving a new command. The guard and effect for the passage of time 
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arc slightly complicated, though. We cannot let time pass indefinitely. In 
particular, if one of the timers would reach a value that it enables a transition, 
we cannot delay past that value. In a state s, we can delay by an amount t if 
the expression shown in Figure 4.28 holds. We see that in failsafe mode, it 
doesn’t make sense to react to the expiration of the failsafe timeout again. The 
effect of a delay is that the timers advance and the continuous variables change 
according to the solutions of their differential equations. This is shown in the 
pvs code in Figure 4.29. In this bit of PVS code, X and V are pvs functions 
that encode the solution of the differential equations for position and speed as 
well as taking care of the changes in acceleration due to reaching the requested 
speed. Each uses the delay d, the current speed s0‘ speedTl, the requested 
speed sO 1 reqspll and the acceleration constant a to calculate the resulting 
position or speed after the delay. Parts of the PVS code for this are shown in 
figure 4.30. The leading train is assumed just to move forward a nonnegative 
amount. This kind of nondeterministic behavior is difficult to formalize in PVS, 
which is the cause of the odd-looking EXISTS clause in the formula. 



StatusEf feet (sO : States , si : States) : bool = 
si = sO WITH 

[ xl := sO'posTl, vl := s0‘ speedTl, 
x2 := sO‘posT2, c := 0 ] 



Figure 4.27. PVS code for the effect of the status transition. 

Delay (s) (t) : bool = s‘c + t <= P AND 
( s'ens + t <= FP DR s'failsafeTl ) 



Figure 4.28. PVS code for the delay guard. 

DelayEffect(sO,d,sl) : bool = EXISTS (p : nonneg_real) : 
si = sO WITH 

[ posTl := sO'posTl + X(d, s0‘ speedTl , sO ‘reqspTl , a) , 
speedTl := V(d, sO ‘ speedTl , s0‘ reqspTl , a) , 
posT2 := sO‘posT2 + p, c := s0‘c + d, 
ens := s0‘cns + d, now := sO'now + d ] 



Figure 4.29. PVS code for delay effect. 

X_ramp(d:Time,v:nonneg_real,a:real I v+a*d>=0) : nonneg_real = 
d*v + a*d*d/2 



Figure 4.30. Dynamics of the train's position. 
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All of this translation work, from StateChart to pvs code, is fairly straight- 
forward. It should be possible to create a tool that translates from the industry- 
standard xmi representation of the UML StateChart to pvs code, whence we 
can prove the correctness of the system. 

Once we have all the guards and transitions defined with respect to the global 
state of our system, we can formalize the notion of an execution of the State- 
Chart in PVS. Recall that a run of the BART system is a sequence of states and 
actions where each triple of state, action and subsequent-state is legal according 
to the StateChart, i.e. the effect of the action matches the assignments on the 
transition in the StateChart and the subsequent-state represents correctly the 
state reached after the transition. The p vs code for this is shown in Figure 4.31. 
The pvs code shown there is generic in the sense that it does not refer to the 
actions specific to the BART/aatc system. It is paid of out PVS automata 
framework, a collection of definitions, theories, and code that partly eases the 
burden of reasoning about automaton runs. In the next section we will briefly 
examine reasoning about the safety of the AATC that we have designed. 

4.2 Proving that the Controller Works 

Consider the collection of automata shown in Figures 4.25 and 4.26, above. In 
these figures and the subsequent formalization in pvs we described the behavior 
of the BART system as a whole. In order to prove that the behavior shown 
by the system meets the goals that we have set we will first need to formalize 
those goals. Then we will need to prove that all of the states reached by our 
system, i.e. every possible situation that can occur during the operation of our 
design, is safe in that sense. 

Formalizing the Safety Condition. California law states that the trains 
must be kept at least the worst-case stopping distance apart. This intends to 
prevent the trains from colliding. Our safety goal as shown in figure 4.9 is 
formulated solely in terms of the trains not colliding. This is an easier goal to 
formalize and surely embodies the spirit of the law, because it states this for 
every possible situation that can occur. This yields: 



WeakSafety (s : States) : bool = s‘p° s Tl < s‘p° s T2 ; 



PreEff ectOK(pr) : bool = FORALL (i:nat) : 

PreconditionCpr ‘ events (i) ) (pr ‘ states (i) ) AND 
Ef feet (pr ‘ states (i) , pr‘events(i) , pr‘states(i + 1)) 



Figure 4.31. Generic definition of acceptable runs of automata. 
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where posTl represents the real position of the trailing train and posT2 repre- 
sents the position of the leading train. 

Since this safety notion is based on discrete states we might worry that “in 
between” states, as time passes, the safety condition is violated. Figure 4.32 
shows a picture of possible movement where in between safe states, an unsafe 
state is reached. 




Figure 4.32. While both states marked “safe” are indeed collision-free, in between the two 
states the trailing train has caught up to the lead train and caused an accident. 

This situation is easy to imagine when the trailing train is braking, although the 
distance graph of the trailing train will then be a smooth parabola. We claim — 
without proof — that the controller keeps the trains sufficiently far apart that 
situations like this one cannot occur. 

Proving correctness:. The whole proof of correctness of our design was 
done in PVS. This took several weeks of intensive proof work. The reasons it 
took so long were: 

■ PVS is not very effective at manipulating algebraic expressions. This 
made much of the work related to the continuous movement of the trains 
extremely tedious. 

■ The original statement of SafetyCheck from page 119 was insufficiently 
strong to allow us to prove the safety of the system. We needed to 
reformulate the safety condition. 

The stricter formulation of SafetyCheck can be seen in figure 4.33. With 
this stricter formulation we ignore the relative timing of status and command 
messages and use worst-case values for both timeouts and status latency. 

The proof of the safety of this system proceeds as follows: 
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■ Some time before each command message a status message is sent. There 
is also a last status message before each command message, i.e. the most 
recent status message. Suppose that the state is safe — no collision — at 
the time of that most recent status message. 

■ Since the new speed command is sent, there must be a new speed v such 
that SafetyCheck holds. This tells us that the distance between the lead 
and the trailing train must be larger than just the “no collision” distance. 

■ After the status message, the train can have moved at most X (500 , s ‘ vl , 
Vmax,a). Recall that X formalizes the distance travelled in a period of 
time with given starting and target speeds and a fixed acceleration and that 
Vmax=80mph. Since the amount of time since the status message is less 
than or equal to 500ms, and the requested speed is necessarily less than or 
equal to 80 mph and the acceleration is fixed (see the list of simplifications 
on page 120), the train travels less than X (500 , s ‘ vl , Vmax , a) between 
the status message and the command message. This is a trivial exercise 
in lineal - inequalities with quadratic expressions on paper, but an exercise 
in tedium with PVS. At the same time, the train has reached a speed of 
at most lsp (500, s'vl, Vmax). 

■ Suppose that no speed command is ever sent after the one currently under 
consideration. Then the train travels until the timeout is reached — which 
is less than X (2000 , vP , Vmax , a) , and then brakes to a halt, which will 
take less than the worst-case stopping distance of wesd (lsp (2000 , vP , 
Vmax) ) . Therefore the trailing train comes to a stop before it has traveled 
the whole distance separating it from the lead train. This case is safe. 

■ If a second speed command is sent, then we first determine that all the 
status messages after the first command message and before the second 
one are safe - no collision occurs. This proceeds along si mi lar lines as 



lsp(d,v0,v) : Speed = IF vCKv THEN V(d,v0,v,a) ELSE vO ENDIF ; 

Saf etyCheck(s , v) : bool = 

LET vP = lsp (500, s ‘ vl , 80) "/, max speed after last status 

IN v <= 80 AND 
s‘xl 

+ X(500, s ‘ vl ,80, a) "/, worst case position increase 

+ X(2000,vP,80,a) % worst case increase until fail stop 

+ wcsd(lsp(2000, vP, 80) ) °/ 0 consider worst case, i.e., largest speed 
< s‘x2 



Figure 4.33. Stricter definition of SafetyCheck in PVS. Constants (500, 2000) denote times 
in milliseconds. 80 is the maximum speed in miles per hour. 




Environmental Modeling with UML 



127 



the previous case: we calculate how far the train can move at most and 
find that it is less than the distance separating the two trains at the moment 
the first new speed command is sent. 

Since all the status messages between this speed command and the next 
are safe, then the next speed command occurs in the same kind of situation 
as the current speed command: there is a recent status message in a safe 
state. This returns us to the first step of this proof outline. 

Using an inductive proof style, this proof outline translates into some 200 lem- 
mas in PVS which prove the safety of the system. 

5. Results raised by this technique 

In this chapter, we have applied our 5-step approach to the BART case study. 
We have concentrated on modeling the environment of the AATC system, en- 
abling us to find inconsistencies, incompleteness, and inaccuracies in the in- 
formal requirements document. The tracing activity on page 109 — re-reading 
the informal document with a set of formal diagrams at hand — yields 5 issues 
that need to be resolved in order to create an accurate model. These may be 
considered omissions (instances of incompleteness) in the informal document. 
The activity that checks the meaning of the diagrams discovered an additional 
issue with respect to the drive states in the motor controller on page 115. Most 
of these finds were repaired in our model; none were life-threatening, but they 
do serve to illustrate how difficult it is to write a truly accurate informal re- 
quirements document and how a care tul and methodical formalization can help 
improve it. 

In section 4 we designed a controller for the model of the environment we have 
created. This controller was proven to be correct with respect to its assumptions 
(which were many, not always realistic, simplifications of the system). While 
this does not necessarily belong to the activities of Requirements Engineering, 
it does serve to illustrate that the 5-step approach yields diagrams that arc useful 
beyond the Requirements Engineering part of the software life-cycle. 

6. Conclusion 

In this paper, we demonstrated the steps we have taken to obtain a careful and 
accurate model of the behavior of the trains of the B ART/aatc system. Using 
this model, we designed a controller system for the trains and after an additional 
translation step into the logic of the pvs theorem prover, we proved that the 
controller was correct with respect to the safety aspects of California law. 

The method yields useful improvements to the informal requirements document. 
Future work will evaluate if the tools used — currently XFig for drawing the 
diagrams and PVS for formalizing those diagrams — is a good choice. We 




128 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



suspect that a combination of an actual UML tool, such as Argo U ML, and a 
theorem prover with better support for algebraic manipulation, such as COQ, 
will be a better choice in the long run and will enable a greater degree of 
automation in the process. 
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Checking BART Test Scenarios with UML’s Object Constraint Language 
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Abstract 

The Object Constraint Language (OCL) is part of the Unified Modelling Lan- 
guage (UML). Within software engineering, UML is regarded today as an im- 
portant step towards development of high-quality object-oriented systems. OCL 
allows to sharpen UML diagrams through invariants and pre- and postcondi- 
tions. This chapter explains the functionality of the UML Specification Environ- 
ment USE, which allows to validate and verify UML and OCL descriptions. 

The paper shows that central safety properties of the BART system can be ex- 
pressed with OCL. Test cases embodying central aspects of the BART system 
can be formulated within the USE system. It can be shown that the safety prop- 
erties are satisfied by the test cases examined. 



1. Introduction 

The Unified Modeling Language (UML) [OMG03] is regarded today as a very 
important standard for the development of software systems. UML originated 
from its main predecessor approaches Booch [Boo94], OMT [RBP+91], and 
OOSE [JCJ092]. UML is a graphical modelling language supporting many 
phases in the software development cycle by offering diagrams and language 
features meeting the special needs in respective phases. Many commercial 
tools for UML are available. The Object Constraint Language (OCL) [OMG03, 
WK98] is part of standard UML, but up to now OCL is not supported by most 
commercial tools. OCL is a specification language supporting and enriching 
the UML with textual details which cannot be expressed in diagrammatic form. 
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OCL allows to precisely describe system structure by invariants and system 
behavior by pre- and postconditions. 

Tool support for OCL is beginning to develop. Among the first available tools 
was our system USE (UML Specification Environment) [RicOl]. USE is based 
on conceptional work on the formal semantics of the OCL, the needed relevant 
UML features [RG01] and work on the metamodel of OCL [RG99]. The main 
task of USE is to validate and verify specifications developed within UML and 
OCL. By validation we mean that the developer can animate the specification 
by providing a number of test cases and check whether the USE responses meet 
the intuition. Verification is supported in restricted form [GR02] . Especially 
for specifications involving formal aspects we regal'd validation systems as ex- 
tremely helpful because they give feedback to developers in early development 
stages. By verification we mean, that the test cases are formally checked with 
respect to invariants and pre- and postconditions. Other tools for OCL include 
the commercial tool from Boldsoft [Bol02], an OCL compiler [HDFOO], and 
the KeY tool [ABB+00]. 

USE is now available as version 2.0. 1 and has achieved more and more func- 
tionality since it was first introduced. USE is the only OCL tool allowing in- 
teractive monitoring of OCL invariants and pre- and postconditions. USE has 
been successfully applied in various case studies and in teaching UML. It was 
employed in submissions for the upcoming new version of UML and has been 
used for large specifications like the UML metamodel with about 100 classes 
and hundreds of OCL expressions. USE offers the following functionalities: 

1 syntax check for and browsing through textual UML and OCL descrip- 
tions, 

2 generation of system states through object, attribute and link manipula- 
tion, 

3 representation of system states as object diagrams, 

4 monitoring model inherent and explicit invariants in class diagrams, 

5 operation execution and monitoring of pre- and postconditions, 

6 representation of operation call sequences as sequence diagrams, and 

7 querying system states with OCL expressions. 

For realizing these functionalities, the USE system covers central UML lan- 
guage features. The input to USE are UML class diagrams in textual form, 
OCL invariants, and OCL operation descriptions through pre- and postcondi- 
tions. USE produces as output UML object and sequence diagrams as well as 
reports on the validity of invariants and pre- and postconditions in table and text 
form. 
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The central idea of the USE tool is to check for software quality criteria like 
correct functionality of UML descriptions already on the design level in an 
implementation-independent manner. This approach takes advantage of de- 
scriptive design level specifications by expressing properties shorter and in a 
more abstract way. Such properties arc given by invariants and pre- and post- 
conditions, and these are checked by the USE system against the test scenarios, 

1. e. object diagrams, state manipulation commands, and operation calls. Such 
abstract design level tests arc expected to be also used later in the implementa- 
tion phase. 

A short version of this paper has been published in [ZG03]. The structure of the 
rest of this chapter is as follows. Section 2 introduces UML, OCL and the USE 
tool. In Section 3 we declare which elements of the case study we consider and 
which we do not. In the central Section 4 the specification is developed and 
validated. The results of our approach arc given in Section 5 and finally our 
contribution closes with a conclusion in Section 6. 

2. Technical approach and method 

Let us start by giving an overview on this section. In Subsection 2.1 we ex- 
plain the running example we use for introducing the UML Specification En- 
vironment USE. Subsection 2.2 shows how class diagrams and constraints arc 
represented in USE. In Subsection 2.3 we elaborate how system states can be 
generated automatically. Subsection 2.4 discusses how to run USE and how to 
get feedback from it. 

2.1 The crossing system 

This introductory example describes a simple traffic control application where a 
controller is supposed to supervise 4 traffic lights on a street crossing. Figure 5 . 1 
shows a UML class diagram with the classes Controller and Light. Fig- 
ure 5 .2 displays two UML statechart diagrams, the left one for class Controller 
and the right one for class Light. 

A Controller object can be linked to the 4 Light objects which are then 
accessible with the role names north, south, west, and east. The controller 
possesses an operation createLights for creating and initializing the lights 
and an operation switch for switching the crossing system. The controller 
is responsible for transmitting a switch operation to the respective lights. A 
Light object possesses 3 attributes r, y, and g for the red, yellow, and green 
bulb, respectively, an internal operation ryg for manipulating the 3 attributes 
and also an operation switch for switching. Furthermore, for convenience, it 
has 3 Boolean-valued operations for checking the displayed signal. 

The Light statechart shows that we describe Italian traffic lights with 3 states 
G, YG, and R. In state G only the green bulb is on, in state YG only the yellow 
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and green bulb, and in state R only the red bulb. The shows predicates, i.e. 
the boolean-valued operations beginning with shows, characterize these states. 
The switch operation in class Light switches between these states in a cyclic 
way. The Controller statechart has 4 states which arc named according to 
the signal on the north and west light. We require that the north and south 
lights coincide as well as the west and east lights. When receiving a switch 
operation, the task of the controller is to transmit the switch to the proper 
Light objects. Essential for our purpose is that certain properties have to be 
satisfied. For example, for safety reasons, the north and the west light arc 
not allowed to display only green at the same time, and they arc not allowed 
to show only red at the same time. The puipose of the UML Specification 
Environment (USE) is to bring life into this description. 



controllerForNorth 
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north 


Light 


|0..1 






1 


Controller 


controllerForSouth 


South 


south 
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Figure 5. 1. Class Diagram for Crossing System. 



2.2 Class diagram and constraint representation in USE 

Class diagrams are given to USE in textual form. In the following, the classes 
Controller and Light arc presented together with their attributes and oper- 
ations. In addition to attribute types and operation signatures, the definition of 
the query operations (in this case, the shows predicates) arc specified by OCL 
expressions. 

model TrafficLight 

class Controller 
operations 

createLights () 
switchQ 
end 

class Light 
attributes 
r : Integer 
y : Integer 
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switch()/north.switch;south.swi 
^ createLightsQ 



^northGwestR j 



switch()/north.switch();south.swit< 
west.switch();east.switch() 




switch()/north.switch();south.switch(); 

west.switch();east.switch() 



( north RwestG) 



switch()/north.switch;south.switch() 




Figure 5.2. Statecharts for Crossing System. 



g : Integer 
operations 

ryg(pr : Integer, py: Integer, pg: Integer) 
switchQ 

showsRQ : Boolean = r=l and y=0 and g=0 

showsGO : Boolean = r=0 and y=0 and g=l 

showsYGO : Boolean = r=0 and y=l and g=l 

end 

Analogously to a class, an association including the association name, the par- 
ticipating classes, their role names and their multiplicities arc described in USE 
textually as follows. We only show the definition of the association North 
because the associations South, West, and East arc described analogously. 

composition North between 

Controller [0 .. 1] role controllerForNorth 
Light [1] role north 
end 

A central description element within USE arc constraints. Constraints come 
in 2 different forms: Invariants as well as pre- and postconditions. Invariants 
characterize conditions which must hold during the complete object life cycle. 
Pre- and postconditions characterize an operation by describing the state before 
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and the state after the execution of the operation. Let us have a look at the Light 
invariants first. The invariant ownedByOneController counts the controller 
objects that a Light object is connected to and restricts this count to one. Thus, 
a Light object lives either as the north, south, west, or east Light object within 
a Controller object. The invariant R_G_YG restricts the state of a Light object 
to the allowed bulb combinations. Thus, for example, when a Light object has 
the red and green bulb both switched on, that is a forbidden state. 

constraints — Invariants for Light 

context Light inv ownedByOneController : — Light ownership 
controllerForNorth->size+controllerForSouth->size+ 
controllerForWest->size+controllerForEast->size=l 

context Light inv R_G_YG: 

— Allowed states for single light 
Bag{showsR() ,showsG() ,showsYG()}- 
->select (b I b=true) ->size=l 

The invariants of the Controller class require that a Controller object is 
associated with exactly 4 Light objects. Furthermore, the north and the south 
light of the controller as well as the west and the east light of the controller have 
to show the same signals. Last but not least, it is required that the north and the 
west lights arc not allowed to show only green or to show only red in the same 
state. 

context Controller inv f ourLightsExist : 

— Lights are different 

Set {north, south, west , east}->size=4 

— Coincidence and non-coincidence 

— for North/South and West/East 

context Controller inv northSouthCoincide : 

north. r=south.r and north. y=south.y and north. g=south.g 

context Controller inv westEastCoincide : 

west . r=east . r and west . y=east . y and west .g=east .g 

context Controller inv northWestNotBothG : 
not (north . g=l and west.g=l) 



context Controller inv northWestNotBothR: 
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not (north . r=l and west.r=l) 

Apart from the above invariants, OCL expressions arc used to specify operations 
with pre- and postconditions. Roughly speaking, the pre- and postconditions 
of the operation switch in the class Light and the pre- and postconditions 
of the operation switch in the class Controller encode the respective state- 
charts shown in Fig. 5.2. The details arc not needed in the following, but arc 
explained in [GR02]. We explain the basic ideas of OCL pre- and postcon- 
ditions using the operation ryg in class Light. The precondition paramsOk 
checks before operation execution that the parameters to be assigned to the 
attributes have values which can lead in principle to a valid system state. The 
postcondition assignedRYG assures that the parameters arc assigned to the 
respective attributes. Be aware of the fact, that the equality symbol in the 
postcondition is a logical equality, not an assignment. Thus, we could have 
written the postcondition equivalently with left and right hand sides exchanged 
as pr=r and py=y and pg=g. 



— ryg — 

context Light: :ryg(pr: Integer, py: Integer, pg: Integer) 
pre paramsOk: 

0<=pr and pr<=l and 0<=py and py<=l and 0<=pg and pg<=l 
post assignedRYG: 

r=pr and y=py and g=pg 

context Light :: switchO — switchO in Light — 
post R_2_G: 

(r@pre=l and y@pre=0 and g@pre=0) implies showsGO 
post G_2_YG: 

(r@pre=0 and y@pre=0 and g@pre=l) implies showsYGO 
post YG_2_R: 

(r@pre=0 and y@pre=l and g@pre=l) implies showsRO 

context Controller :: switchO — switchO in Controller — 
post northRwestG_2_northRwestYG : 

— north. showsRO and west. showsGO 

( north. r@pre=l and north. y@pre=0 and north. g@pre=0 and 
west.r@pre=0 and west.y@pre=0 and west.g@pre=l ) 
implies ( north. showsRO and west . showsYGO ) 

post northRwestYG_2_northGwestR: 

— north. showsRO and west . showsYGO 

( north. r@pre=l and north. y@pre=0 and north. g@pre=0 and 
west.r@pre=0 and west.y@pre=l and west.g@pre=l ) 
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implies ( north. showsGO and west . showsRO ) 

post northGwestR_2_northYGwestR: 

— north. showsGO and west . showsRO 

( north. r@pre=0 and north. y@pre=0 and north. g@pre=l and 
west.r@pre=l and west.y@pre=0 and west.g@pre=0 ) 
implies ( north. showsYGO and west. showsRO ) 

post northYGwestR_2_northRwestG : 

— north. showsYGO and west. showsRO 

( north. r@pre=0 and north. y@pre=l and north. g@pre=l and 
west.r@pre=l and west.y@pre=0 and west.g@pre=0 ) 
implies ( north. showsRO and west. showsGO ) 

context Controller :: createLights () — createLights () — 
pre lightsNotExisting: 

north->size+south->size+west->size+east->size = 0 
post lightsCreatedLinkedlnitialized: 
north. oclIsNew and south . oclIsNew and 
west . oclIsNew and east . oclIsNew and 
north. showsGO and south . showsGO and 
west. showsRO and east. showsRO 

2.3 USE snapshot generator and ASSL 

The basic idea of USE is to validate a UML description by checking whether 
certain test cases meet the expected behavior. Objects can be created and de- 
stroyed, their attributes can be manipulated, and links to other objects can be 
established and deleted. By analyzing the results of the test cases, the devel- 
oper receives feedback about her or his UML description. For examples, she 
or he gets to know whether the invariants arc too strong (too few test cases 
arc accepted) or too weak (too many test cases arc accepted). Part of the USE 
system is a so-called snapshot generator based on the language ASSL (A Snap- 
shot Sequence Language). ASSL specifications try to construct with so-called 
procedures non-trivial system states. An example is the procedure switch in 
the following text. 

procedure switch(theControllers : Sequence (Controller) ) 
begin 

for aController : Controller in [theControllers] 
begin 

[aController . north] . r : =Try ( [SequencefO , 1}] ) ; 

[aController . north] . y : =Try ( [SequencefO , 1}] ) ; 
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[aController . north] . g : =Try ( [Sequence{0 , 1}] ) ; 

[aController . south] . r : =Try ( [Sequence{0 , 1}] ) ; 

[aController . south] . y : =Try ( [Sequence{0 , 1}] ) ; 

[aController . south] . g : =Try ( [Sequence{0 , 1}] ) ; 

[aController .west] .r :=Try( [Sequence{0 , 1}] ) ; 

[aController .west] .y :=Try( [Sequence{0 , 1}] ) ; 

[aController .west] ,g:=Try( [Sequence-[0 , 1}] ) ; 

[aController . east] .r :=Try( [Sequence{0 , 1}] ) ; 

[aController . east] .y :=Try( [Sequence{0 , 1}] ) ; 

[aController . east] ,g:=Try( [Sequence{0 , 1}] ) ; 
end; 
end; 

The procedure switch is given a sequence of controllers. In the body of the 
procedure every attribute of each controller is given a value from the specified 
domain {0, 1}. In the case of the procedure switch, after all attributes have 
been assigned a value, it is checked whether all invariants are valid. If this 
is the case, the attribute assignments arc reported and can be executed. If no 
valid system state has been found for the attribute assignment in question, the 
ASSL generator backtracks and tries other assignments for the attributes. Thus, 
it is tried to construct a valid system state, i.e. a state where all invariants arc 
satisfied. A successful construction yields a sequence of USE manipulation 
commands which applied to a current state result in a new valid state. The 
further employment of the generator will be explained below. 

2.4 Running USE 

This subsection explains how the USE system is employed to validate UML 
descriptions. We do so by showing commands given to USE and the responses 
of USE. 

The first step is to read a UML description and then to initialize the crossing sys- 
tem. After having started USE, 2 windows arc available for communication with 
USE: One window with a graphical user interface (GUI) and one window with a 
command line interface. Both interfaces have advantages in certain situations. 
Loading a model can be done through the GUI or as demonstrated below with 
the open command. The file trali .use contains the above explained textual 
description of the class diagram, the invariants, and the pre- and postconditions. 
Afterwards 1 Controller object and 4 Light objects are created (! create), 
the object arc linked ( ! insert) and the attributes arc manipulated ( ! set). 

use> open trali. use 



use> ! create c: Controller 
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use> 


! create 


n: 


Light 




use> 


! create 


s : 


Light 




use> 


! create 


w: 


Light 




use> 


! create 


e : 


Light 




use> 


! insert 


(c 


,n) 


into 


North 


use> 


! insert 


(c 


,s) 


into 


South 


use> 


! insert 


(c 


,w) 


into 


West 


use> 


! insert 


(c 


,e) 


into 


East 


use> 


! set 


n. 


r=0 








use> 


! set 


n. 


y=o 








use> 


! set 


n. 


g=i 








use> 


! set 


s . 


r=0 








use> 


! set 


s . 
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use> 


! set 


s . 
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use> 


! set 
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r=l 
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! set 
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! set 
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! set 


e . 
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use> 


! set 


e . 


y=0 








use> 


! set 


e . 


g=0 









Figure 5.3 shows how a screenshot of the GUI after having executed the above 
USE commands. In the left part we see a project browser allowing to inspect the 
classes, the associations, the invariants, and the pre- and postconditions. The 
Controller invariant northWestNotBothG is selected and shown in detail 
below the project browser. In the right paid we see 4 windows opened through 
buttons in the top paid of the GUI window. We see an object diagram win- 
dow, a class invariants window, a class extent window, and an OCL expression 
evaluation window. The object diagram window shows that in the current sys- 
tem state the traffic can pass in west-east direction, but the traffic has to stop in 
north-south direction. The class invariants window tells us that all invariants arc 
evaluated to true in the current system state. The class extent window presents 
all Light objects together with their attribute values in table form. The OCL 
expression evaluation window allows to formulate an ad-hoc query against the 
system state and displays the result. 

As shown below, checking of invariants is also supported on the command 
line interface via the command check. First, the model-inherent invariants, 
namely the multiplicity specifications from the class diagram, arc checked and 
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Figure 5.3. Screenshot of the USE system. 

afterwards the explicitly given invariants. The option -d stands for showing a 
detailed result in the case that an invariant fails. We will see an example for 
this further below. 

use> check -d 
checking structure . . . 
checking invariants... 

checking invariant (1) ‘Controller: : f ourLightsExist ’ : OK. 
checking invariant (2) ‘Controller: :northSouthCoincide’ : 

OK. 

checking invariant (3) ‘Controller :: northWestNotBothG’ : OK. 
checking invariant (4) ‘Controller : :northWestNotBothR’ : OK. 
checking invariant (5) ‘Controller: : westEastCoincide ’ : OK. 
checking invariant (6) ‘Light : :R_G_YG’ : OK. 
checking invariant (7) ‘Light :: ownedByOneController ’ : OK. 
checked 7 invariants in 0.070s, 0 failures. 
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In order to work with the snapshot generator we will need additional invariants, 
which can be loaded dynamically and whose validity can be switched on or off. 
In this case, the invariants characterize the states of a controller. Note that the 
invariant name corresponds to the name of a respective state. Each of these 
invariants is placed in a separate file with a corresponding name. 

context Controller inv northGwestR: 

self . north . showsGO and self . west . showsRO 

context Controller inv northYGwestR: 

self .north . showsYGO and self .west . showsRO 

context Controller inv northRwestG: 

self . north . showsRO and self . west . showsGO 

context Controller inv northRwestYG : 

self . north . showsRO and self . west . showsYGO 

These additional invariants are loaded from the respective files. Afterwards 
each of the invariants is switched off by setting the deactivate flag for that 
invariant. 

use> gen load northYGwestR. invs 
Added invariants: 

Controller: : northYGwestR 
use> gen flags Controller :: northYGwestR +d 

use> gen load northRwestG. invs 
Added invariants: 

Controller: : northRwestG 
use> gen flags Controller :: northRwestG +d 

use> gen load northRwestYG . invs 
Added invariants: 

Controller: : northRwestYG 
use> gen flags Controller :: northRwestYG +d 

use> gen load northGwestR. invs 
Added invariants: 

Controller: : northGwestR 
use> gen flags Controller :: northGwestR +d 



Next we turn on exactly one of the newly added invariants, namely the one 
aiming for the state where the north light only shows yellow-green and the west 
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light only shows red. Remember that we are currently in state northGwestR. 
Thus the aim is to make the first transition on the state cycle in the Controller 
statechart. The generator is stalled with the gen start command by specifying 
the ASSL hie and the procedure in that ASSL hie to be executed (there can 
be more than one procedure in a single ASSL hie). After entering the gen 
result command, the generator reports that it has checked 1765 snapshots 
and was successful in hnding a valid system state. It shows the sequence of 
USE commands producing that state. We execute that command sequence with 
the gen accept command, turn off the temporarily switched-on invariant and 
demonstrate with the check command that all invariants are indeed satished. 

use> gen flags Controller : :northYGwestR -d 
use> gen start trali.assl switch(Sequence{c}) 
use> gen result 

Random number generator was initialized with 8372. 
Checked 1765 snapshots. 

Result: Valid state found. 

Commands to produce the valid state: 

! set n.r = 0 
! set n . y = 1 
! set n . g = 1 
! set s . r = 0 
! set s . y = 1 
! set s . g = 1 
! set w.r = 1 
! set w . y = 0 
! set w . g = 0 
! set e . r = 1 
! set e . y = 0 
! set e . g = 0 

use> gen result accept 

Generated result (system state) accepted. 

use> gen flags Controller : :northYGwestR +d 

use> check -d 
checking structure . . . 
checking invariants... 

checking invariant (1) ‘ Controller :: f ourLightsExist ’ : OK. 
checking invariant (2) ‘ Controller : :northSouthCoincide ’ : 
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OK. 

checking invariant (3) 
checking invariant (4) 
checking invariant (5) 
checking invariant (6) 
checking invariant (7) 



'Controller: inorthWestNotBothG’ : OK. 
'Controller: :northWestNotBothR’ : OK. 
'Controller: : westEastCoincide ’ : OK. 
'Light : :R_G_YG’ : OK. 

'Light: : ownedByOneController ’ : OK. 



checked 7 invariants in 0.010s, 0 failures. 



In order to show how to work with USE in the case of invariant failure, let us 
look at the following command sequence. The west and east light currently 
show only red. We now provoke an invariant failure by switching off the 
red bulb of only the east light. We show the essentials of the current system 
state by giving a query to the USE system and afterwards check the invariants 
with the detail option. We learn that 2 invariants fail, namely the invariants 
Controller: : westEastCoincide and Light: :R_G_YG. Due to the detail 
option we see that controller c and light e are responsible for that invariant 
failure. We then reset the red bulb to the original status and again show the 
essentials of the current system state by evaluating a query. 

use> ! set e.r=0 



use> ?Sequence-[n.r ,n.y,n.g, s.r,s.y,s.g, w.r,w.y,w.g, 
e.r,e.y,e.g> 

-> SequencefO, 1 , 1 , 0,1,1, 1,0,0, 0,0,0} : Sequence (Integer) 

use> check -d 
checking structure . . . 
checking invariants... 

checking invariant (1) 'Controller: : f ourLightsExist ’ : OK. 
checking invariant (2) 'Controller: :northSouthCoincide ’ : 

OK. 

checking invariant (3) 'Controller : :northWestNotBothG’ : OK. 
checking invariant (4) 'Controller : :northWestNotBothR’ : OK. 
checking invariant (5) 'Controller: : westEastCoincide’ : 
FAILED. -> false : Boolean 
Instances of Controller violating the invariant: 

-> Set{@c} : Set (Controller) 
checking invariant (6) 'Light : :R_G_YG’ : FAILED. 

-> false : Boolean 

Instances of Light violating the invariant: 

-> Set{@e} : Set (Light) 

checking invariant (7) 'Light :: ownedByOneController ’ : OK. 
checked 7 invariants in 0.010s, 2 failures. 
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use> ! set e.r=l 

use> ?Sequence-[n.r,n.y,n.g, s.r,s.y,s.g, w.r,w.y,w.g, 
e.r,e.y,e.g> 

-> SequencefO, 1 , 1 , 0,1,1) 1,0,0, 1,0,0} : Sequence (Integer) 

Last but not least, we show that even the answer of the USE system that 
no valid system state was found may be meaningful. In the following com- 
mand sequence we activate two conflicting invariants, namely the invariants 
Controller : : northYGwestRand Controller : : northRwestG. Essentially, 
we aim at a system state where the controller is in both states from the state- 
chart. In this case, the generator reports that it cannot find a valid system state. 
Indeed, it also reports that it has checked all 4096 = 2 12 possible system states. 
The 2 12 states originate from the 4 lights with each light having 3 attributes and 
each attribute having 2 possible values. 

use> gen flags Controller : :northYGwestR -d 
use> gen flags Controller :: northRwestG -d 
use> gen start trali.assl switch(Sequence{c}) 
use> gen result 

Random number generator was initialized with 9833. 
Checked 4096 snapshots. 

Result: No valid state found. 

3. Inputs taken from the BART case study 

In this section we describe the elements of the case study we chose to specify 
and those we chose to drop or modify. Some subsections are named like sections 
of Chap. 1, making it easy to find the corresponding parts in that chapter. 

3.1 Objective and general aspects 

Our objective is the specification of a simplified version of the Bay Area Rapid 
Transit (BART) system and of an algorithm that can control the speed and 
acceleration of trains in this system (Par - . 1-3). 

A track of the BART system is partitioned into track segments. Segments 
may be bounded by gates (Par. 9). Station computers, which are pari of the 
Advanced Automatic Train Control (AATC) system, control the trains in their 
immediate area by giving speed and acceleration commands to the trains. In 
each control zone, up to 20 trains can be handled (Par - . 11). We abstract from 
communication links between computers and trains, the on-board train control 
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system, managing entry and exit of trains into the system, and hand-offs between 
stations (Par. 12). We assume that the interlocking system does not close a gate 
when it is too late for an approaching train to stop, not even as a signal to 
following trains. This is a modification to Par. 13. 

The control algorithm is subject to various constraints. These include the 3 
constraints stated in Par. 14: 

■ A train should not enter a closed gate. 

■ A train should never get so close to a train in front that if the train in front 
stopped suddenly the (following) train would hit it. 

■ A train should stay below the maximum speed that track segment can 
handle. 

We do some major simplifications: When controlling the trains, we assume that 
the station computers have direct access to speed, acceleration, and position 
information of the trains. We do not care about uncertainty envelopes and 
mean and standard deviation (Par. 16). Also, we do not attach time stamps 
to commands (Par. 17). A commanded speed and acceleration is valid until a 
new commanded speed and acceleration is given, they do not expire ( Par. 18). 
Station computers arc not divided into vital and non-vital station computers 
(Par. 19-21). 

3.2 Inputs and outputs to the control algorithm 

The control algorithm has access to all relevant attributes of all trains, includ- 
ing position, speed, acceleration, length, and currently commanded speed and 
acceleration. Information of the track is also available, i.e., location and grade 
of segments, maximum allowable speed, and location and state (open, closed) 
of gates. 

The output of the algorithm is a commanded speed (between 0 and 80 mph) 
and a commanded acceleration (-2 to -0.45 mphps in braking, 0 to 3 mphps in 
propulsion) for a given train. 

3.3 Physical performance of the train in response to 
commands 

When given a speed and acceleration command, the train will accelerate to 2 
mph under the commanded speed at the indicated acceleration. We neglect the 
fact that maximum acceleration depends on speed. Once a speed 2 mph below 
the commanded speed is achieved, the train will attempt to maintain that speed 
(Par. 29). 

We assume that the open-loop braking mode is never used. Therefore, the 
maximum braking rate is 2 mphps (i.e., an acceleration of -2 mphps). The 
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worst case profile assumes maximum braking rates below 2 mphps anyway 
(Par. 31-32). The minimum braking rate is 0.45 mphps ( Par. 34). 

Opposing to the original case study description, it takes no extra time to move 
from propulsion into braking and vice versa. Moreover, changing acceleration 
(positive as well as negative) from ct\ to «2 always takes 0.5 seconds, no matter 
of the values of a\ and a -2 (Par. 35-36). Grades have an influence on actual 
accelerations (Par. 37). 

3.4 Worst case stopping profile 

Speed and acceleration of a train has to be selected so that (1) the train does not 
hit a train in front of it or (2) enter a closed gate, not even in the case of very 
poor stopping conditions (Par. 38). We adopt the complete worst case stopping 
profile calculations exposed in Table 1.1 and 1.2 and described in Par. 39-4-9. 
During Validation (Sect. 4), we decided to modify the calculation in one major 
point: We use v instead of vcm (Par. 42), because otherwise the stopping could 
be too optimistic if vcm is lower than v. We adopt this worst case model, even 
though in our simplified system the worst case would not be such bad (mode 
change takes no extra time etc.). 

Speed and acceleration must be consistent with worst-case safety bounds. We 
do not have any secondary objectives (Par. 50). Some secondary objectives of 
the BART case study (e.g. regarding the passengers comfort) possibly will be 
accomplished but we neither put any effort in it nor do we test such properties. 

4. Applying the approach to the case study 

In this section, we will see U M L and OC L in action when working on the BART 
case study. We develop a specification consisting of several different parts. In 
Sect. 4.1, the existing train system is modelled by a UML class diagram with 
additional OCL constraints. All side effect-free operations of the classes arc 
specified by OCL expressions that calculate the results. The safety requirements 
that must be satisfied are also specified in this section. In Sect. 4.2, the physical 
behavior of trains is specified by a procedure that gets the watch half a second 
ahead and moves the trains accordingly. In Sect. 4.3 we then present a simple 
control algorithm, that is expected to meet the requirements in the environment 
set in Sect. 4. 1 with trains behaving as specified in Sect. 4.2. Finally, we validate 
all parts of the specification by loading running tests in different scenarios in 
Sect. 4.4. 

4.1 Specifying the problem with UML and OCL 

Specifying the problem starts with the construction of the object model with 
class operations being described by OCL expressions as result values. OCL 
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constraints specify the requirements each instantiation of the object model (i.e., 
each system state) must fulfill. 

The basic object model. The UML class diagram in 5.4 depicts the object 
model all further specifications refer to. A segment belongs to a track. The 
attributes of class Segment capture begin, end and length of the segment as well 
as civil speed, grade and exposure. Segments are ordered by an association 
SegmentOrder. A station platform is a special segment additionally having a 
name. Segments can be bounded by gates at the segment end. The attribute 
open of class Gate indicates whether the gate is open or closed. A train is located 
on a track. The attributes of class Train hold the location of its nose, its speed v, 
acceleration a, commanded speed vcm and commanded acceleration acm. The 
length of the train is also recorded. A train is originating from a station platform 
and has another station platform as destination. A station computer controls 
trains on a part of the track. This part is determined by a segment at which 
it begins (role sb) and one at which it ends (role se). The operations of the 
classes with no side-effects arc specified in the following sections. 




Figure 5.4. UML object model of train system. 



Operations of class Train. The operation currentSegO computes the 
segment on which the train is currently located. The segment belongs to the 
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track the train is located on and the nose of the train is somewhere between 
begin and end of the segment. The construct ->asSequence () ->f irst(), 
occurring in the operation definition below, is often used to get the element 
from a set with exactly this one element in it. 

currentSegO : Segment = 
self . track . segment 

->select (segBegin <= self. nose and segEnd > self. nose) 
->asSequence () ->f irst () 

The operation nextTrainQ finds the train which is in front of the given train. 
It is the train it has to be avoided to crash into. 

nextTrainQ : Train = 

let candidates = self . currentSegO .nextPlusO 
->collect (currentTrains () ) 

->f lattenO 

->select(t | t.nose > self. nose) 

->asSequence() in 
if candidates->isEmpty () 
then candidates->f irst () 
else candidates->iterate (t : Train; 
result:Train = candidates->f irst () | 
if t.nose < result. nose then t else result endif) 
endif 

The operation nextClosedGateO gives the next coming gate that is closed. 
The operation first () applied to an empty sequence results in Undefined, 
so this is the result of nextClosedGate () if there is no closed gate coming. 

nextClosedGateO : Gate = 

let candidates = self . currentSegO .nextPlusO 
->collect (gate) 

->select(not open) 

->asSequence() in 
if candidates->isEmpty () 
then candidates->f irst () 
else candidates->iterate(g:Gate; 
result: Gate = candidates->f irst () | 
if g . segment . segEnd < result . segment . segEnd 
then g else result endif) 
endif 

The next stop of a train is either at the next closed gate or at the back of the next 
train or at the end of its destination segment, depending on what is nearer. The 
operation nextStopO calculates the absolute position of this place. 
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nextStopO : Real = 

let candidates = Sequencefself . dest . segEnd, 
self .nextClosedGateO . segment . segEnd, 
self .nextTrainO .nose - self .nextTrainQ . length} 
->reject (isUndef ined) in 
candidates->iterate(s :Real; 

result :Real = candidates->f irst () | 
if s < result then s else result endif) 

The station computer that is responsible for the train changes depending on the 
position. The operation stationComputer () results in the currently respon- 
sible computer. 

stationComputer () : StationComputer = 

StationComputer . alllnstances 

->select(sc | self . currentSegO .nextPlus () 

->includes (sc . se) ) 

->select(sc | 

sc . sb . segBegin <= self . currentSegO . segBegin and 
sc.se. segEnd >= self . currentSegO . segEnd) 
->asSequence () ->f irst () 

Operations of class Segment. The operation nextPlus () applied on 
a segment results in a sequence that includes the segment itself and all next 
coming segments. It uses the auxiliary operation nextPlusAuxO. 

nextPlus () : Set (Segment) = 

nextPlus Aux (Set {self }) ->r eject (isUndef ined) 

nextPlusAux(s : Set (Segment) ) : Set (Segment) = 
if s->collect (seg | seg.next) 

->exists(seg | s->excludes (seg) ) 
then nextPlusAux(s->union(s->collect (seg | seg.next)) 
->asSet) 
else s 
endif 

The operation previousPlus () analogously gives the previous segments. 

previousPlus () : Set (Segment) = 

pr e vPlus Aux (Set {self }) ->r eject (isUndef ined) 

prevPlusAux(s : Set (Segment) ) : Set (Segment) = 
if s->collect (seg I seg. previous) 

->exists (seg | s->excludes (seg) ) 
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then prevPlusAux(s->union(s->collect (seg | seg .previous) ) 
->asSet) 
else s 
endif 

The operation currentTrains ( ) is the inverse of the operation current Seg ( ) 
of class Train. It gives all trains that arc currently located on the segment. 

currentTrains () : Set (Train) = 

Train. alllnstances->select (currentSegO = self) 

Operations of class StationComputer. The operation trains () is the 
inverse of the operation StationComputer () of class Train. It gives all the 
trains the station computer is currently responsible for. 

trains () : Set (Train) = 

Train. alllnstances->select (StationComputer () = self) 

The operation wcsd() calculates the worst case stopping distance of a train t. 
The operation adheres to the formulas given in Table 1 . 1 on page 1 4 and Table 1 .2 
on page 15 with one exception: we use v instead of vcm in line 7 and 17. 
Otherwise the calculation would be to optimistic if vcm is lower then v. In line 
46-49 the result is calculated by addition of dl, d2 and d7 if the train is braking, 
or by addition of dl to d7 otherwise (see Par. 47). 

1 wcsd(t : Train) : Real = 

2 let pu:Real = 3.0 in 

3 let puf: Integer = 6 in 

4 let dl:Real = (puf*pu) in 

5 

6 let ad: Real = 2 in 

? let d2:Real = t.v*ad in 

8 

s let tjp:Real = 1.5 in — jerk time in propulsion 

10 let ap:Real = 3 in — acceleration in propulsion 

11 let jp:Real = ap/tjp in — jerk limit in propulsion 

12 — acceleration due to grade: 

13 let a:Real = -21 . 9*t . currentSegO • grade/100 in 

1 4 then -1.5 

15 let d3:Real = t.v*tjp + l/2*ap*t jp*t jp + 

io l/ 6 *jp*t jp*t jp*t jp + l/ 2 *a*t jp*t jp in 

17 

is let v3:Real = t.v + ap*tjp + l/2*jp*t jp*t jp + a*tjp in 

is let me: Real = 1 in — mode change 

20 let d4:Real = v3*mc + l/2*a*mc*mc in 



— position uncertainty 

— position uncertainty factor 

— no noise 

— AATC delay 
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let v4:Real = v3+a*mc in 

let near: Integer = 10 in — number of car in consist 

let nf ail : Integer = 2 in — number of failed cars 

let nfsmc : Integer = 2 in — number of cars in FSMC 

let qfsmc:Real = (ncar-nf ail-nfsmc)/ncar in 
let brk:Real = if t . currentSegO . exposure=#open 
then -1 . 5 
else -2.0 

endif in — design brake rate 

let jb:Real = -1.5 in — jerk limit in braking 
let tjb:Real = brk/jb in 

let d5:Real = v4*tjb + l/6*jb*qf smc*t jb*t jb*t jb 
+ l/2*a*t jb*t jb in 

let v5:Real = v4 + l/2*jb*qf smc*t jb*t jb + a*tjb in 
let fsmc:Real = 8.5 in — fail safe mode change time 
let t6:Real = f sme-t jp-mc-t jb in 
let bfs:Real = brk*qfsmc in 

let d6:Real = v5*t6 + l/2*bf s*t6*t6 + l/2*a*t6*t6 in 

let v6:Real = v5 + bfs*t6 + a*t6 in 

let q:Real = (ncar-nf ail) /near in 

let vf=0 in — final speed (mph) 

let d7:Real = (vf*vf - v6*v6)/(2*(brk*q + a)) in 

if t . a < 0 

then dl+d2+d7 

else dl+d2+d3+d4+d5+d6+d7 

endif 



We do not show the OCL expression for the operation wcsd2() because there 
are only a few differences to wcsdQ. The distance computed by wcsd2() 
is more pessimistic than the one calculated by wcsd(): (1) The accelera- 
tion due to grade always presumes a grade of -4%, i.e. the subexpression 
t . currentSegO . grade is replaced by -4 in line 13. (2) Brake rate is always 
only 1.5, therefore, the lines 27-30 arc replaced by let brk : Real = -1.5. 
(3) Acceleration is presumed to be positive so that all distances dl to d7 are 
added up. Hence, the lines 47-50 are replaced by dl+d2+d3+d4+d5+d6+d7. 
This more pessimistic stopping distance is less fluctuating so it is more suitable 
for our control algorithm as we shall see. 
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OCL constraints on the train system. The invariant fitting states that 
the end of a segment is equal to the begin of the next segment if there is a next 
segment. 

context Segment inv fitting: 
self . next . isDefined implies 
self . next . segBegin=self . segEnd 

The length of a segment has to be the difference of segment end and begin: 

context Segment inv correctLength: 

self . segEnd-self . segBegin = self. length 

Connected segments belong to the same track: 

context Segment inv track: 

self .next . isDefined implies self. track = self .next .track 

The origin and the destination of a train have to be connected by a sequence of 
segments: 

context Train inv line: 

self . orig.nextPlus()->includes(self .dest) 

A train can not be commanded to travel faster than 80 mph or slower than 0 
mph (Par. 27): 

context Train inv vcm: 

self.vcm >= 0 and self. vcm <= 80 

The commanded acceleration is either between 0 and 3 or between -2 and -0.45 
mphps (Par. 27): 

context Train inv acm: 

(self.acm >= 0 and self. acm <= 3) or 
(self. acm >= -2 and self.acm <= -0.45) 

A station computer is able to calculate the worst case stopping distance only of 
trains that are in the region the computer is responsible for: 

context StationComputer : :wcsd(t : Train) : Real 
pre : self .trains()->includes(t) 

The same holds for the controlling of trains: 

context StationComputer: : control (t : Train) 
pre: self .trains()->includes(t) 

A station computer is responsible for at most 20 trains (Par. 11): 
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context StationComputer :: trains () : Set (Train) 
post: result->size () <= 20 

The segments that bound the region a station computer is responsible for arc 
connected. 

context StationComputer inv bounderies: 
self . sb .nextPlus () -> includes (self . se) 

The last 3 invariants form the central paid of the specification. They formalize 
the main constraints of the train system. The control () operation has to 
be designed in a manner that assures that these invariants do not fail. The 
constraint civilSpeedSaf ety demands that a “train should stay below the 
maximum speed that segment of track can handle” (Par. 14). 



context StationComputer inv civilSpeedSaf ety : 
self .trains()->forAll(t | 

t.v <= t . currentSegQ . civilSpeed) 



„A train should not enter a closed gate” (Par - . 14). The invariant with the name 
closedGateSaf ety says that if a next closed gate exists, the distance to it is 
greater than the worst case stopping distance of the train, i.e. the train can stop 
in time. 



context StationComputer inv closedGateSaf ety : 
self .trains()->forAll(t | 

t .nextClosedGateO . isDef ined implies 
t .nose+self . wcsd(t) < 
t .nextClosedGateO • segment . segEnd) 



„A train should never get so close to a train in front that if the train in front 
stopped suddenly (e.g., derailed) the (following) train would hit it” (Par - . 14). 
The invariant crashSaf ety says (analogously to the preceding invariant) that 
if a train in front exists, the distance to it is greater than the worst case stopping 
distance of the (following) train. 



context StationComputer inv crashSaf ety: 
self .trains()->forAll(t | 

t .nextTrainO . isDef ined implies 
t .nose+self .wcsd(t) < 

t .nextTrainO .nose-t .nextTrainO .length) 
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4.2 Moving the trains 

We want to validate our specification by simulating trains travelling on a track. 
An operation is needed that implements the physical behavior of trains as time 
elapses by setting the attributes of the trains as they would be after 0.5 seconds 
have gone by. Because such an operation obviously has side-effects, a pure 
OCL expression does not suffice to specify it. Therefore, move () is an ASSL 
procedure that modifies the attributes of all train according to the OCL expres- 
sions that constitute the bulk of the procedure, move ( ) does not correspond 
with any operation of the object model. 

procedure move() 

var 

delta: Real, 
gradeacc: Real; 

begin 

delta := [0.5] ; 

for t: Train in [Train. allInstances->asSequence ()] 
begin 

gradeacc := [21 . 9*t . currentSegO . grade/100*-l] ; 

[t] .nose := [ 

let n = t.nose + t.v*delta + l/2*t . a*delta*delta 
+ l/2*gradeacc*delta*delta in 
if t.v = 0 and t.vcm = 0 then t.nose 
else n endif] ; 

[t].v := [ 

let speed = t.v + l/2*t . a*delta 
+ l/2*gradeacc*delta in 

if (t.v = 0 and t.vcm = 0) or speed <= 0 then 0.0 
else speed endif] ; 

[t].a := [ 

let noseAtNext = t.nose + t.v*delta 
+ l/2*t . a*delta*delta 
+ l/2*gradeacc*delta*delta in 
let grade = t . currentSegO .nextPlus () 

->select (segBegin <= noseAtNext 
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and segEnd > noseAtNext) 

->asSequence()->first() .grade in 
if (t.v = 0 and t.vcm=0) then 0.0 else 
if ((t.v > (t.vcm-2) and t.acm > 0) or 
(t.v < (t.vcm-2) and t.acm < 0)) 
then 21 . 9*grade/100 
else t.acm endif endif] ; 

end; 

end; 

The procedure loops over all existing trains (line 10). The variable gradeacc 
holds the acceleration due to grade (line 13). In line 15-19 the position of the 
nose is calculated by means of the appropriate physical formula. However, if 
both v and vcm arc 0, the position remains unchanged, i.e., the acceleration due 
to grade does not have any effect. The train is “fixed” as soon as it has once 
stopped. 

In line 21-25 the new speed is computed. The train can not go backwards 
(Par. 66), so if the result of the computation is negative the speed is set to 0, the 
train stops. The speed is also set to 0 if both v and vcm arc 0. 

The acceleration is set in line 27-39. If both v and vcm arc 0, acceleration is set 
to 0, too, i.e. the train is “fixed” again. If the speed has achieved the commanded 
speed (± 2 mph) the trains attempts to maintain this speed by compensating 
the acceleration due to grade. To do this, the grade of the segment the train will 
be located on in the next state is considered. If the commanded speed is not 
achieved yet, the acceleration is set to the commanded acceleration. Therefore, 
it takes the train 0.5 seconds to set a new acceleration, no matter how it differs 
from the current one. 

4.3 A simple control algorithm 

The ASSL procedure control (t : Train) implements the operation of class 
StationComputer that calculates the new commanded speed and acceleration 
for a train t. These values have to respect the constraints of the train system 
including civilSpeedSaf ety, closedGateSaf ety and crashSaf ety. The 
algorithm inspects the section of the track that begins with the nose of the train 
and is twice as long as the (more pessimistic but less fluctuating) worst case 
stopping distance wcsd2(t) (line 13). Only maximum speeds and obstacles 
within this range are considered. 

procedure control (t: Train) 
var 

range: Real, 
gradeacc: Real, 
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delta: Real, 
vcmCivilSpeed: Real, 
commandedSpeed: Real, 
commandedAcc : Real; 

begin 

delta := [0.5] ; 

range := [t . stationComputer () .wcsd2(t) *2+100] ; 
gradeacc := [21 . 9*t . currentSegO . grade/100*-l] ; 

vcmCivilSpeed := [ 

let civilSpeeds = t . currentSegO . nextPlus () 
->select (segBegin <= t . nose+range) 

->collect (civilSpeed) 

->asSequence in 

civilSpeeds ->iterate (speed: Real; 

result: Real = civilSpeeds->f irst () | 
if speed < result then speed 
else result endif)] ; 

commandedSpeed := [ 

if t .nextStop()-t .nose < range 
then 0.0 else vcmCivilSpeed endif]; 

commandedAcc := [ 

let pos = t . currentSegO .nextPlus () 

->select (segBegin <= t . nose+range) 

->select (civilSpeed = vcmCivilSpeed) 
->collect (segBegin) ->asSequence in 
let dl = pos->iterate (p : Real; 
result: Real = pos->first() I 
if p < result then p 
else result endif) - t.nose in 
let acc = 

if dl <= 0 then t.a+0.5 

else ( (vcmCivilSpeed-2) * (vcmCivilSpeed-2) 

- t . v*t . v) /(2*dl) - gradeacc 
endif in 

let acmCivilSpeed = 

if (acc < 0 and acc > -0.45) then -0.45 
else acc endif in 
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let d2 = t.nextStopQ - t.nose 

- t . stationComputer () . wcsd2(t) in 
let acc= - (t . v*t . v) /(2*d2) - gradeacc in 
let acmNextStop = 

if t .nextStop()-t .nose > range then t.a+0.5 else 
if (acc < 0 and acc > -0.45 and 

d2 > t.v*delta + l/2*gradeacc*delta*delta) 
then 0.0 
else 

if (acc < 0 and acc > -0.45 and 

d2 <= t.v*delta + l/2*gradeacc*delta*delta) 
then -0.45 else acc endif 
end if 
endif in 

let acm = 

if acmCivilSpeed < acmNextStop then acmCivilSpeed 
else acmNextStop endif in 

if acm < -2.0 then -2.0 else 

if acm > 3.0 then 3.0 else 

if acm < 0 and acm > -0.45 then -0.45 else 

if t.v <= 0.5 and commandedSpeed = 0 then -2.0 

else acm endif endif endif endif] ; 

[t] .vcm := [commandedSpeed] ; 

[t].acm := [commandedAcc] ; 
end; 

The attributes vcm and acm are set in line 73-74 to commandedSpeed resp. 
commandedAcc. commandedSpeed is calculated in line 26-28. It is set to 0 
if the next stop (closed gate, back of next train or end of destination station 
platform) is within the range. Otherwise it is set to the lowest of all civil speeds 
within the range (vcmCivilSpeed, which is calculated before). 

The determination of commandedAcc in line 30-7 1 is a little bit more complex. 
First (line 31-46), the acceleration acmCivilSpeed is calculated. The calcula- 
tion of this acceleration only considers civil speed restrictions, other constraints 
can be violated. acmCivilSpeed is set to the acceleration that is needed to 
achieve a speed 2 mph below vcmCivilSpeed at the beginning of the next 
segment with vcmCivilSpeed as civil speed, so a violation of the invariant 
civilSpeedSaf ety should be avoided. If the train happens to be already on 
that segment, acmCivilSpeed is set to the current acceleration incremented 
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by 0.5 mph. If the resulting acceleration is between 0 and -0.45, which is not 
an allowed commanded acceleration (Par. 27), it is rounded off to -0.45. 

In Line 48-61, acmNextStop is computed. If the next stop is out of the range, 
acmNextStop is set to the current acceleration incremented by 0.5 mph. Other- 
wise, it is set to let the train stop wcsd2 (t) feet before the obstacle. In this way, 
a violation of the invariants closedGateSaf ety and crashSaf ety should be 
avoided. Because wcsd2(t) is shrinking when the train gets slower, the train 
finally stops in a (hopefully) reasonable distance to the obstacle. If the resulting 
acceleration is between 0 and -0.45, it is rounded up to zero if this does not 
causes a constraint violation and rounded off to -0.45 otherwise. If it would 
always be rounded off, the train would stop too soon, which is not desired. 
Note that the algorithm presumes that the new acceleration is set immediately 
in spite of the 0.5 seconds it takes. However, this is not critical because of the 
more pessimistic stopping distance it uses. 

acm (line 63-65) is set to the minimum of acmCivilSpeed and acmNextStop. 
The acceleration is truncated to be in the allowed span (line 67-71). Finally, 
if the commanded speed is 0 and the train is already slower then 0.5 mph, the 
train is commanded to stop with an acceleration of -2 mphps. This has be done 
to avoid a problem that reminds of Zeno’s paradox of Achilles and the turtle: 
Roughly speaking, the train never reaches its stopping point because this point 
is slided forward a little bit each step. 

4.4 Validation with USE 

In this section we show how our OCL specification can be validated with the 
USE tool. 

Preparation. In order to validate our control algorithm, we create a USE 
specification (in a file bart .use) that contains the object model (see Fig. 5.4) 
including the specifications of the side effect-free operations and the OCL 
constraints. The two ASSL procedures move() and control (t: Train) 
arc put into a file procs.assl. At next we create a command tile named 
oneTrainThrough . cmd that contains USE commands to create objects and 
links and to set attribute values according to the sample track (Par. 79). Grades of 
type transition are set to a proper concrete grade. In oneTrainThrough . cmd, 
which respresents our first scenario, one train with the name Choochoo and 
length 710 is set at the end of Daly City Station Platform with all attributes 
(other than length) set to zero. The resulting object diagram is shown in 
Fig. 5.5. 

The first thing we encounter after opening the specification (open bart . use) 
and executing the command tile (read oneTrainThrough.cmd) is that the 
constraint Segment : : fitting is violated several times, i.e., the sample track 
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Figure 5.5. UML object model. 



contains some inconsistencies: Some segments are overlapping, others have a 
gap between them. 



use> check 

checking structure . . . 
checking invariants... 
checking invariant (1) 
checking invariant (2) 
-> false : Boolean 
checking invariant (3) 
checking invariant (4) 



‘ Segment : : correctLength ’ : OK . 

' Segment :: fitting’ : FAILED. 

'Segment :: track’ : OK. 

' StationComputer : :bounderies’ : OK. 




Checking BART Test Scenarios with U M L ’.v Object Constraint Language 



163 



checking invariant (5) ‘StationComputer : : civilSpeedSaf ety ’ : 
OK. 

checking invariant (6) ‘StationComputer : : closedGateSaf ety ’ : 
OK. 

checking invariant (7) ‘StationComputer : : crashSafety ’ : OK. 
checking invariant (8) ‘Train: : acm’ : OK. 
checking invariant (9) ‘Train: : line’ : OK. 
checking invariant (10) ‘Train: :vcm J : OK. 
checked 10 invariants in 15.751s, 1 failure. 

We now get more details about the violation of Segment: : fitting. The 
checking mechanism of USE cancels the examination of a constraint when the 
first violation is detected, so we get only the first violating instance: 

use> check -d Segment :: fitting 
checking structure . . . 
checking invariants... 

checking invariant (1) ‘Segment : :fitting’ : FAILED. 

-> false : Boolean 

Instances of Segment violating the invariant: 

-> Set{@Seg_12300} : Set (Segment) 
checked 1 invariant in 0.028s, 1 failure. 

A look into oneTrainThrough . cmd reveals a gap between position 12369 and 
12969 . After having repaired this, 3 failures of the same type occur, which 
we all relieve either by insertion of another segment or by modification of a 
segment’s attribute values. The inconsistencies arc repaired in the final version 
of the sample track layout that is now included in this book (Par. 79 ). 

In order to minimize typing when running a test, we create a command tile 
step . cmd with the following content: 

gen start procs.assl control (Choochoo) 

gen result 

gen result accept 

gen start procs.assl control (Chattanooga) 

gen result 

gen result accept 

gen start procs.assl move() 

gen result 

gen result accept 

The generator extension of USE is told to execute control (Choochoo) to 
control the train Choochoo. However, the execution does not yet effect a change 




164 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



of the system state-the result is a sequence of USE commands that arc shown 
with the command gen result and executed with gen accept. The same 
is done for the train Chattanooga , which is added in other scenarios described 
below. In scenarios with only 1 train, the controlling lines for the other arc 
deleted. The last 3 lines move the trains and therefore do a 0.5 seconds step 
into future. 

To spare even more typing, we create a file run . cmd that contains x times the 
command read step.cmd, so we only needed to execute run. cmd to run x 
steps. The activity diagram in Fig 5.6 shows the overall strategy for running a 
test. First, the specificaton file is opened. Then, one of the scenarios is loaded 
by executing the corresponding command file. We proceed with the execution 
of run . cmd, which executes step . cmd several times, step . cmd in turn calls 
the control procedure to control Choochoo (and Chattanooga if necessary) 
and move() to elapse another 0.5 seconds. 



bart.use J 



JoTT] 



[oTG] 



( read oneTralnThrough.cmd 




[tTOW] 



[tm 



( read twoTrainsOneWaits j 
thread oneTrainGate.cmd ) ■' read twoT rainsThroughcmcj ) 




Figure 5.6. UML activity diagram showing the activities that are performed during a test run. 
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The Test Scenarios. We want to run four different test scenarios, differing 
from each other in the state of the gates (open or closed) or the number of existing 
trains and in their origin, destination and current location. These scenarios arc 
shown in Fig. 5.7. 



Daly City Gate Balboa Park Glen Park Mission 24th 



1 : Choochoo I ^ oTT 

, closed 

2: Choochoo I oTG 

open / 

3: Choochoo I — — / Chattanooga I ^ tTOW 

open / ; ^ 

4: \ ->■ Choochoo r Chattanooga I tTT 



Figure 5. 7. The four test scenarios. The markers mark the ends of the station platform segments 
and the location of one gate. 1: oneTrainThrough.cmd (oTT), 2: oneTrainGate . cmd (oTG), 
3: twoTrainsOneWaits . cmd (tTOW). 4: twoTrainsThrough . cmd (tTT). 

We already mentioned the first scenario that is created by executing the com- 
mand file oneTrainThrough.cmd. Only one train Choochoo is created. It 
is put at the end of Daly City Station Platform with all attributes set to zero 
(except for length which is set to 7 10). The train’s origin is Daly City Station 
Platform, its destination is 24-th Street Mission Station Platform. In this sce- 
nario, we want to validate that the constraint civilSpeedSaf ety is respected. 
In addition, the behavior of the train when stopping at its destination can be 
observed. 

In the second scenario (created with oneTrainGate . cmd), we want to observe 
the train when stopping in front of a closed gate. Therefore, we set the attribute 
open of the gate at position 12369 to false. All other settings remain the same 
as in the first scenario. 

Next, we want to examine the interplay of 2 trains, so we add another train 
Chattanooga in twoTrainsOneWaits . cmd. Its origin is Balboa Park Station 
Platform, the destination is Glen Park Station Platform. The test run starts 
with Chattanooga at the end of Balboa Park Station Platform with speed and 
acceleration set to 0. Choochoo is expected to wait behind Chattanooga when 
Chattanooga arrives at its destination. 

In the fourth scenario, we continue with the preceding scenario by changing 
the destination of Chattanooga from Glen Park Station Platform to 24-th Street 
Mission Station Platform. Choochoo is supposed to regain speed as soon as 
Chattanooga is away and finally stop behind Chattanooga at 24-th Street Mis- 
sion Station Platform. 
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The console output after a step looks like this (taken from the first scenario): 
run . cmd> read step . cmd 

step.cmd> gen start procs.assl control (Choochoo) 
step.cmd> gen result 

Random number generator was initialized with 1286. 

Checked 1 snapshots. 

Result: Valid state found. 

Commands to produce the valid state: 

! set Choochoo. vcm = 36 
! set Choochoo. acm = 0.3248 
step.cmd> gen result accept 
Generated result (system state) accepted, 
step . cmd> 

step.cmd> gen start procs.assl move() 
step.cmd> gen result 

Random number generator was initialized with 1953. 

Checked 1 snapshots. 

Result: Valid state found. 

Commands to produce the valid state: 

! set Choochoo . nose = 7323.01379999999 
! set Choochoo. v = 34.6836 
! set Choochoo. a = -0.1752 
step.cmd> gen result accept 
Generated result (system state) accepted. 

If the execution of one of the procedures violates a constraint, the output notes 
that no valid state is found. In this case, the system state will not be modified. 
The job of the specifying engineer is to find the reason for this violation by 
looking into the details of the procedure execution with the -d option of the 
gen start command and by reproducing parts of the procedure with the USE 
OCL expression evaluator. 

5. Results raised by this technique 

The easiest way to work with USE is to first specify a UML class diagram and 
some OCL constraints and then on the one hand create object diagrams that 
represent valid system states and on the other hand create objects diagrams that 
represent invalid system states. Then it is checked with USE whether those 
system states are really valid resp. invalid in the specified system, i.e. the 
specification is validated. 

To validate the specification in this way, it is necessary to create system states 
that can confidently be regarded as “has to be valid” or “must not be valid”. 




Checking BART Test Scenarios with U M L ’.v Object Constraint Language 



167 



Once the specification is considered as correct, more complex system states that 
arc not easily understandable can be checked with respect to the specification. 
In this chapter, we specified the existing train system with a class diagram, 
OCL result expressions for the side effect-free class operations, and OCL 
constraints. The physical behavior of the trains was specified by the ASSL 
procedure move ( ) . This constitutes our specification. 

The ASSL procedure control (t : Train) also is a specification in the sense 
that we mainly used OCL to describe the effect of the operation but we refer 
to it as implementation that satisfies the safety requirements that arc part of the 
specification. 

Therefore, we had to validate the specification with respect to our intuition so 
that after that the implementation could be validated with respect to the specifi- 
cation. In fact we validated both at the same time by running the test scenarios. 
Syntax errors are of course quickly located and corrected. Several semantic 
errors in the specification were found immediately after loading the initial state 
of a scenario, e.g. inconsistencies in the sample track indicated by constraint 
violation. Finding errors while moving the trains can be more complicated 
because of the interdependence of specification and implementation. There arc 
4 different cases: 

1 A constraint is violated and we judge this violation as unjustified. E.g. 
the constraint civilSpeedSaf ety is violated although the speed of all 
trains is below the allowed maximum speed. In this case, the specification 
is incorrect and the implementation is correct (in this context). 

2 A constraint is violated and we judge this violation as justified. E.g. the 
constraint civilSpeedSaf ety is violated and indeed one train exceeds 
the civil speed. In this case, the implementation is incorrect and the 
specification is correct (in this context). 

3 No constraint is violated but we observe that one of the system states is not 
allowed. E.g. the constraint civilSpeedSaf ety is not violated although 
one train exceeds the civil speed. In this case, both implementation and 
specification are incorrect. 

4 No constraint is violated and we do not detect any unallowable system 
states. This is the aim of our validation process but there are of course 
some uncertainties: (1) Maybe other test scenarios lead to one of the 
cases above. This is a general problem of validation by test scenarios and 
has to be antagonized by proper selection of test scenarios. (2) Maybe 
the implementation is correct with respect to our demands but not with 
respect to the specification that allows some undesired system states. 
We could not detect the bug in the specification. This is critical if the 
specification is supposed to be used later for another implementation. 
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The validation exposed numerous errors of our specification and implemen- 
tation. The specification/implementation shown in the previous section is the 
final version that resulted from several steps of refinement. The exposed errors 
can be categorized as follows: 

1 Syntax errors. These errors of course can be found and corrected quickly. 

2 Small mistakes like the inconsiderate use of < instead of <= or a forgotten 
algebraic sign. 

3 Faults or inconsistencies in the case study description that have been 
adopted in the formal specification. Examples of this kind arc the ques- 
tionable use of vcm instead of v in the calculation of the the worst case 
stopping distance and the formula for acceleration due to grade, which 
has to be multiplied with - 1 to give the correct value. 

4 Constants that arc not adjusted properly. An example is the constant 0 . 5 
in line 68 of control (t : Train) , which previously was a 0 . 2. 

5 Errors in reasoning. For example, in control (t : Train), setting the 
acceleration so that the train stops a constant distance feet behind the train 
ahead does not guarantee that cr ashSaf ety is always respected because 
the worst case stopping distance could temporarily be longer than the 
distance to the next train. 

After refinement of the specification (which induced the present specification), 
the test runs finally yield the following results: 

1 In the first scenario, Choochoo finally stops at position 32741, which is 
240 feet before the the end of 24-th Street Mission Station Platform. 

2 In the second scenario, it stops at position 12123, which is 246 feet before 
the closed gate. 

3 In the third scenario, Chattanooga stops at position 21944, which is 27 1 
feet before the end of Glen Park Station Platform. Choochoo stops at 
position 20986, which is 260 feet before the back of Chattanooga, which 
is 7 10 feet long. 

4 When changing the destination of Chattanooga from Glen Park Station 
Platform to 24-th Street Mission Station Platform (fourth scenario), Chat- 
tanooga regains speed and finally stops at position 3274 1 , which is 240 
feet before the end of 24-th Street Mission Station Platform. Choochoo 
waits until the distance to Chattanooga has increased and then regains 
speed as well. Choochoo finally stops at 31778, 253 feet before the back 
of Chattanooga. 
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Two things attract attention: First, the trains stop in a distance to the obstacle that 
might be longer than necessary. Second, the speed of the trains is seldom higher 
than 36 mph, the lowest of the civil speeds within the sample track. In scenario 
one, the maximum speed of Choochoo is 39.37 mph even though maximum 
allowed speed is temporarily 80 mph. A reason for both is the used worst case 
stopping distance, which might be too pessimistic. The low maximum speed 
also results from the specific sample track. Trains would get faster on tracks 
which do not have low civil speeds on long distances. Flowever, we rate our 
specification as sufficient as the putative deficiencies do not concern safety. 

6. Conclusion 

We have described the functionality of the U M L Specification Environment USE. 
USE allows to validate formal specifications by providing test cases and check- 
ing whether the system’s responses meet the intuition. USE covers validation 
and verification aspects. 

We have expressed the central safety requirements from the BART case study 
through OCL invariants. If these invariants arc satisfied, it is guaranteed that 
no accident can occur. In our specification, the invariants arc assumed to be 
checked every 0.5 second. If a situation involving a closed gate or a stopped 
train in front of a running train is encountered, appropriate action to reduce 
speed of the running train is taken. 

We have used 4 test scenarios covering central situations occurring in the 
BART case study. If one wants to put more resources into the BART develop- 
ment with USE, further test cases covering more situations could be examined 
in much the same way. 

Future work will consider the further development of USE. The results of eval- 
uating pre- and postconditions in the command window could be represented 
in the GUI. Invoking and finishing operations could also be supported interac- 
tively. In order to increase the computational power of operations one could 
consider programming language-like features, i.e. conditionals and loops, for 
the command interpretation. 
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Abstract Design of reliable distributed systems is stretching limits in term of complexity 
since existing development techniques are usually not fully accurate for this type 
of applications. One of the main problem is the gap between the various notations 
used during development process. Even if UML is an important step forward in 
this domain, it is not fully suitable for formal description of distributed systems. 
In this chapter, we present the L/P (Language for Prototyping) notation. It is 
dedicated to formally describe distributed (potentially embedded) systems. We 
show how L/P may serve as an input for formal verification using Data Decision 
Diagrams (DDD). an extension of Binary Decision Diagrams (BDD) enabling a 
compact representation of state spaces. Some aspects of the BART case study 
will be presented and we show what type of behavioral properties we may verify 
on this specification. 



1. Introduction 

The fast evolution of distributed technology has lead to systems stretching 
limits in terms of complexity and manageability [Lev97]. This generates a 
major problem when distributed systems have to be certified. The problem 
resides at both the design and coding phases: collected requirements may be 
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incomplete, inconsistent or misunderstood and the numerous interpretations of 
a large specification often leads to unexpected implementation. 

The problem comes from the gap between the various notations used in the 
software life cycle (natural languages, specification languages, programming 
languages). A first solution is to use a methodology providing a coherent 
set of notations to solve this problem. UML [OMG99] can be considered as an 
important step forward in this domain because it proposes a standard to describe 
a system specification. 

However, UML semantics is not sufficiently formally defined to enable formal 
verification unless strong restrictions and hypotheses on the way to use it arc 
introduced (like in [Bos99, GLM99]). Moreover, the behavioral semantics of 
UML will not be formally defined for several years since version 2.0 essentially 
formalizes static/structural aspects and introduces OCL to define constraints 
precisely. However, only a very limited number of pages arc dedicated to 
dynamic aspects in [OMGOl]. 

We consider that, for distributed systems, UM L is mostly valuable at early stages 
of the software life cycle. When a preliminary object-oriented solution is elab- 
orated, there is a need for another type of description closer to implementation 
(e.g. that does not rely on complex object oriented middleware like CORBA, 
that cannot be used when time or memory constraints are considered). This new 
description should enable both formal verification (a well accepted approach to 
leverage the quality of distributed systems) and automatic program generation 
(to ensure coherence between specification and program). Program generation 
techniques are out of the scope of this chapter and will not be discussed. 

2. Technical approach and method 

Model-based development [QvSP99] focuses on the use of a model that serves 
as a basis for various purposes: validation, formal verification and automatic 
program generation. We share this opinion and consider that it corresponds to 
an evolutionary prototyping methodology [KL02], 

2.1 Methodology 

We propose a "model based" development approach [GKR02] centered on a 
formal model enforcing strong relations between system modeling, formal ver- 
ification and implementation for distributed systems. We want to provide: 



■ transparent access to formal verification techniques to enable their use in 
an industrial context without requiring heavy training and specific skills 
as outlined in [LG97], 
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■ strong correspondences between the detailed description of a system, its 
proofs and its implementation. In other words: "what you describe is 
what you check and implement" . 

Figure 6.1 outlines our model based development approach and links it into 
a "classical" requirement/analysis phase producing an UML model. We con- 
sider that a reformulation of this initial model to build the central model of our 
approach is necessary to unify behavioral information that arc dispatched into 
several UML diagrams. Most of the work should be automated but the designer 
has to add information required for formal verification (e.g. unambiguous de- 
scription of the system’s behavior, assertions such as "this server has to provide 
an answer") and for code generation (such as "implementation of component 
< C > is in Java"). Such additional information is sometimes located in UML 
tagged values supported by some CASE tools (and thus potentially non stan- 
dard). Let us note that the introduction of OCL [OMGOl] in the last UML 
release allows to describe many of these properties (mostly the one related to 
the system consistency). 



result from formal a nalysis 



transformation formal verification 
reformulation ’ techniques 

UML UP 

. Execution of 

code genemtion ] distributed programs 



result from execution analysis 



Figure 6.1. Outline of our model based development approach. 

We have introduced L/P (Language for Prototyping), a high-level modeling 
language to detail the specification of a distributed embedded system. The 
central L/P model serves as a basis for: 

■ formal verification of the system. Transformations are driven by vari- 
ous verification techniques <formal model , used technique> to produce 
views on the systems on which properties can be automatically verified. 
Based on results, the central model is updated until all properties arc 
satisfied. 

■ Tool based implementation. Program generators produce the source files 
to be compiled and integrated in the target execution environment. This 
step is out of this chapter’s scope. 
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2.2 L/P 

L/P is a formally defined graphical Architecture Description Language with 
coordination facilities focusing on (potentially embedded) distributed systems. 
It enhances an existing UML model with information enabling formal verifica- 
tion as well as automatic program generation of distributed programs. To do 
so, we define three complementary views: 

■ Th e functional view describes the system behavior in terms of execu- 
tion workflow of connected components and the coordination between 
component instances. It also describes the system software architecture. 

■ The implementation view describes the system implementation constraints 
(target execution environment, used programming language, etc.) and the 
deployment topology. 

■ The property view specifies properties to be verified by the system. Such 
properties arc stated by means of invariants (for example, to check mutual 
exclusion), temporal logic formulas (for example, to check availability 
or fairness of a service) or any other statement suitable for formal verifi- 
cation. This view can be exploited to perform computer-assisted formal 
verification but also introduces relevant information for code generation 
(e.g. runtime checks). 

A small example. Let us present a simple client/server system to illustrate 
some L/P features. Clients interact with a server offering a set of services: 
Start Session( ) returning a session id, A Service(sid, s) performing service s 
on session sid and End Session! sid) closing session sid. Figures 6.2 and 6.3 
present the UML class diagram and a sequence diagram for this system. 




Client 1 F2. 

I Start_session() 



A_Service(sid) 



End_Session() 



Server 



Figure 6.2. Example: the class diagram. Figure 6.3. Example: a sequence diagram. 



The architecture diagram. The architecture diagram reproduces the orig- 
inal UML Class Diagram structure enriched with information comprising 
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important elements such as the logical communication infrastructure between 
classes or instanciation of classes. This infrastructure is the root of a hierarchy 
of diagrams defining the behavioral contract for each component of the system. 



- Global declarations 

- Constant to parameterize the Sessionjd type 
const Max_Session : integer := 100; 

type Sessionjd is range (1 .. Max_Session) of integer; 

- Static instances of classes 
staticjnstanciation : S : serveur with (); 
staticjnstanciation : C_1 : client with (); 
staticjnstanciation : C_2 : client with (); 
staticjnstanciation : C_3 : client with (); 
staticjnstanciation : C_4 : client with (); 
staticjnstanciation : C_5 : client with (); 



wv i cs 



Client.s is CS_Chan.cl 



all 




Server.c is CS_Chan.sv 



20 

FIFO 



Figure 6.4. L/P architecture diagram of the example. 

Figure 6.4 presents the architecture diagram for the client/server example. It in- 
troduces CS_Chan, the media describing communication semantics (behavior 
of communication elements). This media is connected to classes by means of 
binders (inspired from binding points in RM-ODP [IT97]). CS_Chan declares 
two ports, cl and sv. Some characteristics of these ports (such as capacity) are 
defined in the architectural diagram (the right binder is a FIFO buffer that can 
hold up to 20 messages). Binders connect communication ports provided by 
classes and media: in the figure, the port cl from CS_Chan is linked to port s 
from Client. 

The architecture diagram of Figure 6.4 also defines the initial instances for the 
system: 1 server and 5 clients. Finally, global types and constants may be 
defined; they are visible on the entire L/P specification. 

Binders define the interaction between a class instance and a media instance (e.g. 
buffering characteristics). They contain information regarding the capacity of 
associated buffer and a cardinality specifying if the corresponding buffer is 
shared between instances of connected classes or not. Let us illustrate how 
the cardinalities of this model should be interpreted. Figure 6.5 shows relations 
between a class and a media and Figure 6.6 shows the unfolded interconnections 
after instanciation. We consider three instances of classes A and B and two 
instances of media Ml and M2. Cardinality 1 means that all connected class 
instances has its own binder while all means that connected class instances 
share one binder. 

Behavioral contract of a class. L/P behavioral diagrams (L/P-BD) rely 
on a sequential state machine notation to unambiguously describe all types of 
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Figure 6.5. Examples of class connections. Figure 6.6. Connections of the instances. 



behavioral contracts in L/P. The behavioral contract describes the activation 
conditions of triggers and methods and is defined using a L/P-BD. Figure 6.7 
presents the protocol for the Server class; the scenario of Figure 6.3 is contained 
in this diagram. 




— Prototypes 

function Start_Session () return Sessionjd; 
procedure End_session (si : in Sessionjd); 
synchrony procedure A_Service (si : in Sessionjd); 

— Variable (shared if there are several instances 

— of the server) 

shared Nest_Session: Sessionjd := 1; 



Figure 6.7. Behavioral contract of the Server class. 

The declarative part of Server defines three methods: Start_Session, A_Service 
and End_Session. The first two methods are synchronous since one is a func- 
tion (a return value is expected by the invoker) and the second one is stated so. 
The last method is asynchronous. Asynchronous methods must be procedures 
with read-only parameters. 

Variable Next_Session is also declared to be shared by all server instances. 

It also declares a binder reference: s to be linked to a binder in the architecture 
diagram (s is linked with sv in Figure 6.4). In the state machine transitions are 
represented by squares. These transitions correspond to a method to be invoked 
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by some other class that belongs to the system or to a trigger to be automatically 
executed when a given condition is locally satisfied. These transitions are a link 
to the behavioral contract of the corresponding method. Figure 6.7 shows that, 
once it is started with a given session identifier the server instance executes 
several times the method A Service and ends when End Session is invoked. 

Behavioral contract of a method. Methods have their own behavioral 
contract, also represented using L/P-BDs. These diagrams have a unique initial 
state and at least one terminal state. 

Figure 6.8 shows the contract of Start_Session. This method is protected with 
a semaphore (mutex) because it manipulates the shared variable Next_Ses- 
sion. Transition create_next_server references the Server constructor and 
creates a new instance of server when fired. This instance will start its execution 
at the initial state of the class behavioral contract. 



b_startsession 



■> 



KO — 



begin 



Next_Session := Next_Session + 1; 



create_new_server 

ns := server (); 



*9' 

d 



&s return (Next_Session) ; 

e_startsession 

< ' 



- 6 - 



•* — E 

end mutex 



o 



- The function prototype 

function Start_Session () return Sessionjd; 

- We temporarily need a reference to a 

- new instance of server 
ns : server; 



Figure 6.8. Behavioral contract of method Start_Session. 



The L/P-BD of Figure 6.8 also references the s binder defined to be an interface 
to other components. Since Start Session is a method, it is activated by an in- 
coming request, referenced as aprecondition in b startsession. A return value 
is sent back to the emitting client before releasing the lock e startsession. 
Let us note that the address of the invoking client is handled by the L/P runtime 
and used to route the corresponding message. Here, the class s is connected 
to a set of media by means of ports as specified in the Architecture diagram 
(Figure 6.4). 

Description of a media. Media have no method. The associated L/P-BD 
describes the communication semantics to be supported. Figure 6.9 shows the 
very simple behavior of media CS_Chan that only relays information from 
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client to server and vice-versa. This media typically represents a simplified 
socket-like mechanism. 



— Variables to store messages 
M_cl, M_sv : message; 

— to enable/disable reception 
enable_cl, enable_sv : boolean := true; 




Figure 6.9. Behavioral contract of media CS_Chan. 



Let us note that an instance of CS_Chan transports only one message at a 
time in a given direction (from cl to sv and vice-versa) ; this is ensured by 
the guard involving the boolean variables on transitions Get_cl and Get_sv. 
A message is stored in a variable according to its direction (M_cl or M_sv) 
; and then delivered when transitions cl and sv arc fired. The type message 
is predefined and represent any message computed from the possible method 
invocation declared in a model. A binder cannot access to the content of a 
lfp_message. When it is necessary (e.g. to route the message), the media 
have to declare a discriminant to be explicitly set when sending a message 
through a binder. Such a mechanism is presented later in this chapter. 

2.3 Operational semantics of L/P 

Operational semantics defines the rules necessary to move from one program 
state to another. In this section, L/P semantics is clarified. L/P allows to define 
high-level actions that must be decomposed since they usually involve actions 
from distant objects. For instance, several messages can be sent (or received) 
within a single L/P transition. Such a transition has to be splitted because it 
cannot be considered as atomic. The number of resulting transitions, each one 
corresponding to an atomic action, is equal to the number of messages sent (or 
received). 

In the following, a state of a L/P program is characterized, and the associated 
operational semantics is further described. 
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State of a L/P program. We arc now in position to define precisely 
the constitutive elements of a L/P program state. For classes and media, the 
elements composing their state can be easily deduced from the specification. 



Global information 


Classj instances and local media 




Class n instances and local media 



Shared variables 


Class instance 


Binders 


Local media 




Class instance 


Binders 


Local media 



Instance attributes 


Program counter 


Stack 




Program counter 


Local variables 



Program counter 


Parameters 


Local variables 




Program counter 


Parameters 


Local variables 



Figure 6.10. L/P state description 

A state (Figure 6. 10) is made of global and local to classes variables. Binders 
with capacity all are global information, since they arc not linked to any par- 
ticular class instance. For the same reason, media that arc not automatically 
instantiated arc also considered as global information. Everything else is con- 
sidered as local to classes information. 

The part of the state describing classes contains: 

■ variables shared by all instances and the related locks (i.e. class vari- 
ables), 

■ class instances information (variables, program counter, stack when meth- 
ods arc invoked), 

■ binders with capacity 1 linked to each instance class, 

■ every media dynamically instantiated with each class instance. 

Semantic of a L/P program. In this subsection, we describe how, from a 
given state of a L/P program, a new state can be reached. 

The atomic transitions considered here systematically modify a program counter. 
They can also assign variables, read or write one message. However, atomic 
transitions can be classified, depending on their impact on the state: method 
invocation or ending, trigger invocation or ending, message sending or recep- 
tion... First of all, we describe a simple transition that only performs a variable 
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assignment, then we study how other kind of transitions modify this basic 
schema. 

The execution of this simple transition is bound to the satisfaction of a guard 
(if not specified, the guard expression is set to true). Executing a transition is 
done in two steps: evaluating if the transition can be executed and execution of 
the transition. 

The transition can be executed if: 

■ the program counter has the right value, 

■ no lock constraint prevents the execution, 

■ the guard is satisfied. 

Executing the transition means: 

■ locking variables if needed, 

■ execution of the assignment instruction, 

■ unlocking variables if needed, 

■ updating the program counter value. 

If the transition is a trigger invocation, there is no assignment instruction to 
perform. Instead, a new level is added to the stack, where the program counter 
and the parameters arc initialised. The program counter of the previous level is 
set to the trigger return value. 

A trigger/method ending is a transition that puts the program counter to the 
trigger/method end place. In this case, an extra action is performed: the current 
stack level is destroyed. If the stack is empty before destruction, then the 
instance is destroyed together with its local binders and media. 

A transition that receives a message must verify before executing that a message 
is ready to be received: 

■ in the corresponding binder if the communication is asynchronous (binder 
capacity is strictly positive), 

■ a transition sending the message must be ready to fire in synchronous 
cases (binder capacity is null) 

After this verification, the transition performs an action: 

■ assign values received in the message to variables, if the transition wait 
for a method result, 

■ adds a new level to the stack, just like a trigger invocation transition, if 
the transition is a method invocation. 
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After this action: 

■ the message is removed from the binder if the communication is asyn- 
chronous, 

■ the two transitions arc simultaneously fired otherwise. 

If the transition creates an instance, the action performed is the creation and 
initialisation of the instance and the related local binders and media. 

2.4 DDD 

Verifying safety properties on a L/P program basically reduces to computing 
the program’s reachability set , that is the set of all states that can be reached 
(along some path) from the program’s initial states. The reachability set can be 
very large, so compact representations for sets of states arc needed. Moreover, 
efficient operations such as equality test, set-theoretic operations, and oper- 
ations corresponding to L/P instructions arc also required on these compact 
representations in order to compute the reachability set. Data Decision Dia- 
grams satisfy all these requirements, and they have been successfully applied 
to the verification of the BART L/P description. 

Data Decision Diagrams (DDDs) are succinct data structures for representing 
finite sets of assignment sequences of the formal := xp, ei ■ = X 2 ', ■■■ ; e n := 
x„) where e, arc variables and x\ arc values. When an ordering on the variables 
is fixed and the variables arc boolean, DDDs coincides with the well-know Bi- 
nary Decision Diagrams [Ake78, BRB90]. If an ordering on the variables is 
the only assumption, DDDs are the specialized version of the Multi-valued De- 
cision Diagrams representing characteristic function of sets. For Data Decision 
Diagram, we assume no variable ordering and, even more, the same variable 
may occur many times in an assignment sequence, allowing the representa- 
tion of dynamic structures: for a stack variable a, the sequence of assignments 
(a := x\ ; a \ = x 2 ; • • • ; a := x n ) may represent the stack content x±X 2 • • • x n . 
Traditionally, decision diagrams are often encoded as decision trees. Internal 
nodes arc labeled with variables, arcs with values (of the adequate type) and 
leaves with either 0 or 1 . Figure 6.11, left-hand side, shows the decision tree for 
the set S = {(a := 1; a := 1), ( a := 1; a := 2; b : = 0), ( a := 2; b := 3)} 
of assignment sequences. As usual, 1 -leaves stand for accepting terminators 
and 0-leaves for non-accepting terminators. Since there is no assumption on 
the cardinality of the variable domains, we consider 0 as the default value. 
Therefore 0-leaves are not depicted in the figure. 

Unfortunately, any finite set of assignment sequences cannot be represented. 
Thus, we introduce a new kind of leaf label: T for undefined. Intuitively, 
T represents any finite set of assignment sequences. Figure 6.11, right-hand 
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Figure 6.11. Two Data Decision Diagrams. 



side, gives an approximation of the set S U { (a := 2; a := 3)}. Indeed, an 
ambiguity is introduced since after the assignment a := 2, two assignments 
have to be represented: a := 3 and b := 3. These two assignments affect two 
distinct variables so they can not be represented, as two distinct arcs outgoing 
from the same node cannot be labeled with the same value (in other words, 
non-determinism is not authorized in the decision tree). 

We now give an overview of Data Decision Diagrams. For a more formal and 
detailed presentation of DDDs, we refer the reader to [CEPA + 02], 

Syntax and semantics of DDDs. In the following, E denotes a set of 
variables, and for any e in E, l )oni(e) represents the domain of e. 

Definition 1 (Data Decision Diagram) The set ID of DDDs is inductively de- 
fined by d £ ID if: 

■ cf 6 {0, 1, T} or 

■ d = (e, a) with: 

- e £ E 

— a : Dom(e) — ► ID, such that { x £ Dorn(e) | a(x) 0} is finite. 

We denote e — ^ d, the DDD (e, a) with a(z) = d and a(x) = 0 for all x z. 

Intuitively, a DDD can be seen as a tree. DDDs 0, 1 and T arc leaves, and a 
DDD of the form (e, a) is a tree whose root is labeled with variable e, and with 
an outgoing arc labeled with v to a subtree a(x) foreach value v £ Dom(e). 
From a practical point of view, as non-accepting branches (i.e. branches ending 
with a 0-leaf) arc not encoded, the “finite support” condition for a ensures that 
DDDs can be implemented (even when variables range over infinite domains). 
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Recall that DDDs represent finite sets of assignment sequences. An important 
feature of DDDs is the capability to approximate sets of assignment sequences 
that are not exactly representable, using the undefined DDD T. Actually, T 
represents any set of assignment sequences, so in other words, T itself is the 
worst approximation of a finite set of assignment sequences. 

More precisely, the meaning [r/J of a DDD d is a set of finite sets of assignment 
sequences. In particular, [T] is the (infinite) set of all finite sets of asssignment 
sequences. When T does not appear in a DDD, the DDD represents a unique 
finite set of assignment sequences (i.e. its meaning is a singleton). Hence, 
such a DDD yields an exact (non approximate) representation and it is called 
well-defined. 

The unique set in the meaning of a well-defined DDD d is the set of assignment 
sequences corresponding to accepting branches (i.e. branches ending with a 
1-leaf) in the tree representation of d. In particular, we have [0] = {0} and 
[lj = {{()}} (where () is the empty sequence of assignments). 

When a DDD is not well-defined, its meaning consists in several finite sets of 
assignment sequences, and one of them is the finite set of assignment sequences 
being represented. Hence, such a DDD yields an approximate representation. 
The meaning of an ordinary DDD cl intuitively corresponds to the set of mean- 
ings of all well-defined DDDs that can be obtained from d by replacing each 
occurrence of T with some well-defined DDD. 

Clearly, if two DDDs d and d' satisfy [c/] C [[r/'J then d is more precise than d' 
since there is less ambiguity in d than in df and we say that cl is better defined 
than d' . Two DDDs are said to be equivalent when they have the same meaning. 

Equivalence checking for DDDs is crucial when DDDs are used to represent 
sets of states. Fortunately, DDDs admit canonical forms so that equivalence 
checking for DDDs in canonical form reduces to (syntactic) equality. Intu- 
itively, from the tree representation point of view, the canonical form of a DDD 
is obtained by replacing with 0 all sub-trees that have only 0-leaves. Two DDDs 
in canonical form are equivalent if and only if they arc equal. Moreover, every 
DDD is equivalent to a DDD in canonical form. 

In the following, we only consider DDDs that are in canonical form. 

Operations on DDDs. First, we generalize the usual set-theoretic operations 

- sum (union), product (intersection) and difference - to finite sets of assignment 
sequences expressed in terms of DDDs. The crucial point of this generalization 
is that all DDDs arc not well-defined and furthermore that the result of an 
operation on two well-defined DDDs is not necessarily well-defined. The sum 
+, the product * and the difference \ of two DDDs arc inductively defined in 
the following tables. In these tables, for any o <G {+, *, \}, a i o a 2 stands for 
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the mapping in Dornfej) — > ID defined by (ap o af) (jc) = «i (x) o 0-2 (jc) for 
allx G Dom(^i). 




These set-theoretic operations on DDDs actually produce the best possible 
approximation of the result. More precisely, if d and d' arc two DDDs, then the 
sum d + d' (resp. the product d * d' , the difference d \ d') is the “best defined” 
DDD whose meaning contains the set {SUS' | S G [r/] and S' G [r/'J } (resp. 
the set {5 n S' | S 6 [rf], S' € [d'J}, the set {S\S' \ S G [r/J and S' G [d']}). 
The concatenation operator defined below corresponds to the concatenation of 
language theory. 




0 if 4 = 0 V 4' = 0 

d' if 4 = 1 

T if 4 = T A d! f 0 

(■ e , a ■ d') if 4 = (e, a) 



Notice that any DDD may be defined using constants 0, 1 , T, the elementary 
concatenation e—F>d and operator +, as shown in the following example. 

Example 1 Let d A be the DDD represented in left-hand side of Fig. 6.11, and 
d[{ the right-hand side one. 

d A = ( a D^l + a^b-S^l) + a^b^l 

dB = a— !-> [a— L>1 + a-L^b— 5->l ] -f- 
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Let us now detail some computations: 



d A +a^a-L> 1 = faJ-H +a^b-^l\ + (b-1+1 +a-L>l) 

f a _L>1 + a-^b-^l) + a^T 



a — 
A 



^a— Ll * a — * T = 0 * T = 0 A a — Ll * = a— 



1*T = T 



d A \ds = 



\ T ) 



Z ~r~ 

= a — ► I 



d„ ■ c — L, [ = (aJ^c^l+a^b-lUc^l + n_L.T 



Homomorphisms on DDDs. In order to iteratively compute the reacha- 
bility set of an L/P program, we need to translate L/P instructions into DDD 
operations. These complex operations on DDDs arc described by homomor- 
phisms. Basically, an homomorphism is any mapping P : ID — > ID such that 
$(0) = 0 and such that P(c/ 1 ) + is better defined than < \ > {d\ + r/9) for 

every d \ . d> € ID. The sum and the composition of two homomorphisms arc 
homomorphisms . 

So far, we have at one’s disposal the homomorphism d * Id which allows to 
select the sequences belonging to the given DDD d; on the other hand we may 
also remove these given sequences, thanks to the homomorphism Id \ d. The 
two other interesting homomorphisms Id • d and d ■ Id permit to concatenate 
sequences on the left or on the right side. For instance, a widely used left 
concatenation consists in adding a variable assignment e\ = x\ that is denoted 
e\ Xl > Id. Of course, we may combine these homomorphisms using the sum 
and the composition. 

However, the expressive power of this homomorphism family is limited; for 
instance we cannot express a mapping which modifies the assignment of a 
given variable. A first step to allow user-defined homomorphism <[> is to give 
the value of <b(l) and of ( h(e x --, d) for any e x -, d. The key idea is to define 
<F(e, a ) as X^jceDom(<>) Ua(x)) and <F(T) = T. A sufficient condition for 

<[> being an homomorphism is that the mappings ( \d„ e, x) defined as <l>(e, x) (d ) = 
<h(g - x . > d) arc themselves homomorphisms. For instance, inc(e,x) = e x+ \ld 
and inc( 1 ) = 1 defines the homomorphism which increments the value of 
the first variable. A second step introduces induction in the description of the 
homomorphism. For instance, one may generalize the increment operation to 
the homomorphism inc(e 1), which increments the value of the given variable 
e\ . A possible approach is to set inc(e i)(e,x) = e— \ld whenever e = e± 
and otherwise inc(e \)(e,x) = e-A*inc(e 1). Indeed, if the first variable is e\, 
then the homomorphism increments the values of the variable, otherwise the 
homomorphism is inductively applied to the next variables. 

The formal definition of inductive homomorphisms can be found in [CEPA 1 02 1. 
The two following examples illustrate the usefulness of these homomorphisms 
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to design new operators on DDD. The first example formalizes the increment 
operation. The second example is a swap operation between two variables. It 
gives a good idea of the techniques used to design homomorphisms for some 
valiants of Petri net analysis. 



Example 2 This is the formal description of increment operation: 



inc(e i)(e,x) = 
inc(e i) (1) = 1 



■*+1 j 

e — ► Id 



ife — e\ 
inc(e i) otherwise 



Let us now detail the application ofinc over a simple DDD: 



inc(b) (a-I^b-L-^c-L^d — 1) 



a-l—>inc(b)(b—?->c-^d-^ 1) 
a-Ub^Id{c^d^ 1) 
a^->b^c^d^A 1 



Example 3 The homomorphism swap(e i , ef) swaps the values of variables e\ 
and e- 2 - It is designed using three other kinds of homomorphisms: rename(e i), 
down(ei,xi), up(e i,xl). The homomorphism rename(e i) renames the first 
variable into e\; down{e i,xi) sets the variable e\ to x\ and copies the old 
assignment ofe\ in the first position; up(e i,xi) puts in the second position the 



assignment e\ = x\. 


( 


rename(e i) o down{e 2,x 


) ife = ex 


swap(e\, ef)(e ,x ) 


= 


rename(e 2) 0 down(e i,x 


) ife = e 2 




l 


e — swap(e 1, £2) 


otherwise 


swap(e i,c 2 )(l) 


= T 






rename (ei)(e,x) 


= <?i 


Id 




rename(e i)(l) 


= T 






down(ei,xi)(e,x) 


■ { 


X -*-1 -r 7 

e — » e — ► Id 
up(e,x) 0 down(ei,xi) 


ife = e\ 
otherwise 


down(e i , jci) (1) 


= T 






up(e i,xi)(e,x) 


"T 3 

*[ 

Sj 

«! 

H 




up(ei,xi)(l) 


= T 







Let us now detail the application of swap over a simple DDD which enliglits 
the role of the inductive homomorphisms: 



swap(b, d){a—k^bLf^c-L^dEL> l) 



aD^,swap(b, d)(bdL±c-L^d-L^ 1) 
a~I^rename{b) o downed, 2)(c-L^d-L^l) 
a—L>rename(b) o up(c, 3) o doum(d, 2)(d-f+l) 
a-I^rename{b) o up{c, 3)(d— h-rf— T>1) 
a-I^renamedfld-L^c-T^d-L^l) 
aD^b^c^d^ 1 
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One may remark that swap(b , e)(a-^b—?->c— L^l) = a— !-*T. 

Implementing Data Decision Diagrams. In order to write object oriented 
programs handling DDDs, a programmer needs a class hierarchy translating the 
mathematical concepts of DDDs, of set operators, of concatenation, of homo- 
morphisms and of inductive homomorphisms. These concepts arc translated in 
our interface by the definitions of three classes (DDD, Horn and Induct iveHom) 
where all the means to construct and to handle DDDs and homomorphisms arc 
given. Indeed an important goal of our work is to design an easy to use library 
interface; so, we have used C++ overloaded operators in order to have the most 
intuitive interface as possible. 

From the theoretic point of view, an inductive homomorphism $ is an ho- 
momorphism defined by a DDD <F(1) and an homomorphism family <&(e, x). 
Inductive homomorphisms have in common their evaluation method and this 
leads to the definition of a class that we named Induct iveHom that contains 
the inductive homomorphism evaluation method and gives, in term of abstract 
methods, the components of an inductive homomorphism: <F(1) and x). 
In order to build an inductive homomorphism, it suffices to define a derived 
class of the class Induct iveHom implementing the abstract methods <F(1) and 

The implementation of our interface is based on the three following units: 

■ A DDD management unit: thanks to hash table techniques, it implements 
the sharing of the memory and guarantees the uniqueness of the tree 
structure of the DDDs. 

■ An HOM management unit: it manages data as well as evaluation meth- 
ods associated to homomorphisms. Again the syntactic uniqueness of 
a homomorphism is guaranteed by a hash table. We use the notion of 
derived class to represent the wide range of homomorphism types. 

■ A computing unit: it provides the evaluation of operations on the DDDs, 
as well as the computation of the image of a DDD by an homomorphism. 
In order to accelerate these computations, this unit uses an operation cache 
that avoids to evaluate twice a same expression during a computation. 
The use of cached results reduces the complexity of set operations to 
polynomial time. Since inductive homomorphisms arc user-defined, we 
cannot express their complexity. 

3. Inputs taken from the BART case study 

In this section we describe the hypotheses of the BART system we consider 
and add some when necessary. 
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3.1 The railroad system model. 

We focus our study on the behavior of trains on a single railway line. This 
line is not circular and is identified by a starting and an ending point. Trains 
always enter at the starting point and leave at the ending point. We do not 
consider the possibility to enter and leave the line at any other point. Therefore 
we consider unidirectional lines that do not share any paid with other lines. It 
is possible to take into account bidirectional lines with two unidirectional lines 
and to concatenate these bidirectional lines to consider shared sections. In this 
case we must consider a new policy to enter and leave the line. A line connects 
several stations where the trains must stop. These hypotheses precise the global 
description of the Bart system given in Par. 7. 

Physical characteristics of the line and trains arc known and expressed using a 
simulation model used to stimulate the modelled system. The simulation model 
allow to compute possible accelerations and decelerations of trains regarding 
their current position, speed and characteristics. 

3.2 The UML model 

According to the hypothesis presented in the previous section, we propose an 
architecture that is first sketched using an UML Class Diagram presented in 
Figure 6.12. It contains 7 classes: 

■ Extern data stores the simulation model of the real world. This in- 
formation is made available to other classes by means of an application 
programming interface that generates the data used to take decisions. 

■ Operator represents the operator who starts the system, may set it into 
alert mode (all train have to stop then) and sets back the system to normal 
mode (trains may circulate). 

■ Line_Manager handles one line. It lets trains enter and acknowledge 
when they leave the track. 

■ Train represents the controller on each train. This controller communi- 
cates with the watchers that handle motions control and collision check- 
ing. 

■ Move_controller and Anti collision system are the watchers. Mo- 
ve_controller insures that the train is going forward and stops at stations 
; Anti_collision_system checks that the current situation cannot lead 
to a collision with the front train. Each train has its own instances of 
watchers. 

■ Comm represents the communication system. It has its own addressing 
mechanism : a unique address is explicitely affected to any component of 
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the system (except for Extern_data). All classes communication (except 
for Extern_data) are handled by Comm. 



Extern„data j ^- 



iTrain 



AntLcollision_system 



(Comm 

Ai pm 



Move_controller 



|i |i |i 

Line_manager 
pi pi 



^operator ^ 



Figure 6.12. UML Class Diagram of the BART speed management system. 



3.3 Specification of components and their interactions. 

Components. The Line_Manager adds trains at the begining of the line 
and suppresses them when they reach the end. It also alerts the trains when a 
manual alarm is raised (all train have to stop) and informs them when this alarm 
ends (the system may restart). The Line_Manager is the only component to 
communicate with all others. 

To each train is associated a Move_controller and an Anti_collision_system. 
The Move_controller manages the motion of a train with respect to its position, 
speed and its distance to the next station. The Anti_collision_system ensures 
that a secured distance remains between the train and its predecessor on the track 
; it instructs the Move_controller when an emergency is detected, forcing the 
train to stop). 

In each train, an embedded calculator updates the speed and the position with re- 
spect to the decision of the Move controller. We identify each calculator with 
its associated train. The location of the Move controllers and anti-collision 
systems is not given. They arc grouped in several centers. The communication 
services require knowledge of communication ports attached to the Move con- 
trollers and anti-collision systems independently of their location, therefore it 
is not necessary to define precisely what a center is. 

Activation of components. We consider an interleaving execution seman- 
tics. Only one action is performed by one component at a given step. All 
possible actions interleaving arc considered, all possible executions arc thus 
studied. 
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A train and its associated components (the corresponding instance of AntLcol- 
lision_system and Move_controller) are executed in an infinite loop. A step of 
the loop is performed during one time unit. The actions performed arc ordered 
according to the following sketch: 

■ The Move controller notifies the calculator of the speed modification to 
apply to the train. 

■ The calculator computes its new speed and position and transmits them 
to the Move controller and to the anti-collision system. 

■ The anti-collision system checks if a collision may happen (i.e. if the 
train and its predecessor arc too close, an urgent stop is necessary). 

When a problem is detected, components perform the following actions: 

■ The Anticollisioncystem informs the Movecontroller of the prob- 
lem. 

■ The Movecontroller orders the Train to stop immediately. 

■ The Train stops as fast as possible. 

Component’s communications. To be independent of location constraints, 
we consider communication services that associate addresses to the processes 
and not to their physical location. If we consider the communication between 
the processes that manage the supervising of a train and the train itself, we have 
to give an address to the train (calculator), the Movecontroller and the anti- 
collision system. Whatever their physical location is, the communication ser- 
vices ensure that their address are not modified. Therefore, Movecontroller 
and anti-collision system can migrate from a center to another. 

We assume that communications are both safe (no message is lost) and fast 
regarding actions to be performed. 

3.4 Properties of the system 

The system has to verify the following critical properties: 

■ Each train stops at each station. 

■ Trains start with specified condition. 

■ No collision is possible. 

■ Speed limits on each sections of the railroad arc respected. 

■ Resources are sufficient for the correct execution of the system. 
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We consider that these properties have to be verified for a safe system. We also 
consider some additional properties: 

■ No deadlock situation can occur. 

■ Synchronous and Asynchronous communications arc correctly performed. 

■ Emergency situation arc correctly handled. 

■ Insertion and removal of trains from the line are correctly sequenced. 

Once the computation of reachable states is performed, one can verify properties 
by implementing the homomorphism that will verify a corresponding assertion. 
We will address again the verification of properties in the experiment section 5.6. 

4. Applying the approach to the case study 
4.1 The L/P diagrams 

We present in this section the L/P diagrams describing the BART system. The 
full model is too complex to be presented here but we selected several relevant 
diagrams, which demonstrate characteristics of L/P from the modeling and 
analysis point of views. 

The architecture diagram. Figure 6.13 shows the L/P architecture diagram 
that is deduced from the UML Class Diagram of Figure 6.12. Going from one 
to another show how some UML problems may be solved. In Figure 6.12, the 
communication system was modeled using a class. We propose to make it a 
L/P media. A similar problem is raised by relations connected to Extern -da- 
ta. No communication mechanisms is explicitely stated and L/P requires a 
media here (lnline_access). 

Let us now explain the declarative section: 

■ A set of constants are declared and may be used everywhere in the model. 
This is a way to easily change some parameters. 

■ Several types are declared and may be used everywhere in the model. 

■ L/P allows both static and dynamic instanciation of classes and media. 
Operator and Extern_data are the only class to be statically instanci- 
ated in the system. In both case, no context is provided and default values 
of local variables arc used. Inline_access is also statically instanciated 
but Comm instances arc created dynamically according to the classes 
related via the binder m_out. Thus, an explicit association is expressed : 
each instance of Comm is associated to a given instance of either classes 
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all 



all 



Extern^data 






lnline_access 






Extem_data.io is Inline_access.server Inline_access.client is all.io 



-- Constants 

define max_speed = 1 00; 
define max_position = 100000; 
define max_distance = 1 0000; 
define max_train = 40; 
define max_adr = max_train * 3; 
define no_adr = 0; 
define adrjnmgr = 0; 



Train 



Anti_collision_system 



Move_controller 



all 



— Types 

type t_speed is range 0 .. max_speed; 
type t_position is range 0 .. max_position; 
type t_distance is range -1 .. max_distance; 
type t_trainid is circular 

range 0 .. max_train; 
type t_adr is circular range 0 .. max_reg; 



c 

all.m_out is comm.m_in 



all.m_in is comm.m_out 



Line_manager.u is comm.ureg 



Operator 




all | 

1 | <4 1 






Il« 

all.r is comm.reg 



LineJVlanager 



-Declaration of static classes instances 
Operator : 1 with (); 

Extern_data : 1 with (); 

— Declaration media instances 
lnline_access : 1 with (); 

Comm : using_binder out; 
-Characteristics of binders 
lnline_access: (server => 0, blocking, fifo, 
client => 0, blocking, fifo); 
Comm: (r => 0, blocking, fifo 
u => 0, blocking, fifo 
in => 5, blocking, bag 
out => 5, blocking, bag); 



Figure 6.13. L/P Architecture diagram of the BART speed control system. 



Train, Anti_collision_system, Move_controlleror Line_Managerand 

models the channel related to it. 

■ Binder characteristics arc also expressed : their size and behavior. A 
binder stores and reads messages with no particular order. 

Class Train. Its behavioral contract is presented in figure 6.14. When an 
instance of Train is created, it starts in state begin and automatically gets into 
the line at its starting point (activation of trigger in line). At state ready , the 
train speed is 0 and its position is set to the position of the departure station. 
Since a train must always be able to process a get_pos request, this method can 
be fired from all running states {ready, moving and stopped). Let us note that 
values in input arcs always give the highest priority to this method. 

To leave state ready, a Train instance has to execute the start method that sets the 
current speed to the minimal possible value. Then the instance reaches the state 
moving. All methods but get_pos have the same priority (inputs arc get value 2). 
Method accelerate is fired when the train is allowed to increase its speed (the 
speed limit is not reached and there is sufficient space before the previous train 
or the station to let the train stop). Method stable is activated when the limit 
speed is reached but nothing requires the train to stop. The main difference 
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— Prototypes 

procedure start (s:inout t_speed; p:inout t_position); 
procedure stable (srinout t_speed; p:inout t_position); 
procedure decelerate (s:inout t_speed; p:inout t_position); 
procedure fast_decelerate (s:inout t_speed; p:inout t_position); 
procedure stop (s:inout t_speed; p:inout t_position); 
procedure get_pos (p:inout t_position); 



-- Instance variables 
s : t_speed := 0; 
p : t_position := 0; 
t:t_trainid := 0; 
mr,ar,oar :t_adr; 



trigger in_line(); 
trigger check (); 
trigger exitJineO; 



get_pos get_pos 




Figure 6.14. L fP Behavioral contract of Train. 

between decelerate and fast ^decelerate is the deceleration factor applied to 
the train : decelerate corresponds to a "normal" brake when fast -decelerate 
does not care about passenger comfort and equipment stress (as mentioned in 
Par. 50). 

To leave state moving, it has to execute the stop method that can only be activated 
if current speed is set to the minimum possible value. When the train is stopped, 
it can either exit the line (trigger exitJline ) if its position corresponds to the last 
station in the line or execute trigger check (i.e. be sure that no passenger is 
blocking a door) to come back into a state where it can move to the next station. 



begin 


bjnjine 


end 




> lU 

&m out: [mr] move controller . ack ( ) ; 


^ w 



Figure 6.15. L/P-BD for trigger in-line. 

Figure 6.15 shows the behavior of trigger in_line that is very similar to the 
two other ones ( check and exit -line). The unique transition notifies the current 
action to the associated instance of Move_controller. 
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The two methods we now present arc representative of class Train. Method 
start (figure 6.16) is very similar in its structure to all the other methods but 
get_pos , that is presented in figure 6.17. 

When method start is fired, it invokes some primitives from the Extern _data to 
get the appropriate informations regarding the simulated environment (variable 
ds gets the speed increment and variable dp gets the position increment). Based 
on the results, it updates the local contexte of the instance (transition update ) and 
sends this updated information to the instance of Move_controller handling 
the instance. 



procedure start (s:inout t_speed; p:inout t_position) is 
-- variables local to the method 
ds :t_speed; 

dp :t_position; s s + ds . 




begin b _ start 



start end 

• 



update &m_out [mr] : method . back ( s , p ) ; 

&m_out [ar] : Anti_collision_system. notify (s,p) ; 
&m_out [oar] :Anti collision system. notify p(s,p) ; 



compute 



ds := &io : extern_data . inc_speed (s,p,t); 

dp := &io : extern_data . dist_variation (s, s+ds,p,t);> 



Figure 6.16. L/P-BD for method start. 

Figure 6.17 shows the structure of a typical accessor call : method get_pos 
retrieves from its context the value of attribute s that stores the current speed 
of the train. The first transition gets the call and the second one returns a value 
to the initiator. 



procedure get_pos (p:inout t_position) is 
end; 

begin b_get_pos e_get_pos end 

• *□ o >m 

&m_in; 3 &m_out [adr_lnmngr] : return (p) ; 



Figure 6. 1 7. L/P-BD for method get_pos. 



Media Generic_addressed_COmm. We also present the generic com- 
munication media used to support all interactions between the classes of the 
system (figure 6.18). As shown in the architecture diagram, it has four ports: 
reg associates an address to the media instance, ureg releases the address and 
activates the destruction of the media instance, m_in emits a message in the 
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media and m_out retrieves a message from the media. Messages arc stored in 
variable stored_m. 




Figure 6.18. behavioral contract for media Comm. 

When an instance of Comm is created, it waits for an address that will be used 
to select the messages to be stored (and retrieved by the appropriate client). 
Then it moves to state ready where messages can be inserted if transition I 
fires (the guard ensure that the message discriminant is equal to the address 
associated with the media instance). Transition O extracts a message from 
variable stored m (the guard blocks if this variable contains nothing). When 
U is fired, the media moves in state purge ; all messages remaining in the input 
binder are removed (transition D) before the instance terminates (transition 
terminate). 

5. State space computation using DDD 

This section details the implementation by means of DDDs of the BART model 
expressed in L/P. 

5.1 State coding by means of DDD structure 

The computation of the reachable states requires a canonical representation of 
a state to enable efficient comparison. 




196 



FORMAL METHODS FOR EMBEDDED DISTRIBUTED SYSTEMS 



It also implies the ability to add the states without generating ambiguities. 
Some simple principles can guaranty that no ambiguity will appeal - despite the 
dynamic characteristics of the state. 

Ordering. To obtain a canonical representation, it is critical that the state 
and all its inner components are built with a defined deterministic order on the 
set of assignments ( variable := value) composing the DDD. 

For example, in order to represent sets of data, we define one single variable 
with different values for each element of the set. The first value always gives 
the size of the set. Additionally, we order the values. The comparison of the 
two sets will then be a simple comparison between the 2 corresponding DDDs 
and doesn’t require a costly algorithm. 

The state of the BART is composed of nested blocks. Each blocks content and 
position within the DDD is deterministically defined. This order defines the 
syntax of the state at all level of the nesting. 

This deterministic order has also the advantage of favorizing memory reuse. 
Sharing of identical portions of the DDD structure is supported by the library. 



Problem caused by dynamicity. Once we have defined a deterministic 
order on the sequences of assignments, and since we want to compute the set of 
reachable states, we need to be able to add all the states with no risk of producing 
ambiguities. The typical case to avoid is illustrated by the figure 6.19 below: 
Note that this case will also happen if the chosen order is not deterministic. 




Figure 6.19. Ambiguity when adding 2 DDDs. 

Such ambiguities are trivially solved when the state is statically defined and 
variables are ordered deterministically. However, when the size of data stored 
in a state can change dynamically in any location of the DDD, ambiguities 




Modeling and verifying behavioral aspects 



197 



arc very likely to happen and the + operation will lose compatibility with the 
definition of the state. 

To avoid this problem, we applied the following guidelines in the representation 
of dynamic structures by means of DDDs: 

■ each block of varying size must be prefixed with a same variable that will 
contain a different value that should depend on the size or/and type of the 
structure, 

■ an instance of a basic structure such as a binder, a set, an array, a vector 
or a multiset is identified by one variable. This same variable is used to 
identify the elements of the structure, 

■ states composed of scalar(s) and/or basic structure(s) use different vari- 
ables and must be built according a common unique order. 

The prefixing of dynamic blocks acts as a sentinel that will guaranty that no 
ambiguities can occure at the rank of the considered block. The differentiation 
will be done at the first variable if the blocks have different sizes or inside the 
block if only the values differ. 

For instance, the multiset structure always starts with the size of the multiset. 
Figures 6.20 and 6.21 illustrate two cases of addition of DDDs representing 
multisets. 




Figure 6.20. Adding 2 multisets when their Figure 6.21. Adding 2 multisets of same size 
sizes differ. when data differ. 



5.2 Structure of the Bart State 

This section presents the coding of the BART state by means of a DDD. We 
use the state description of an lfp program as described in . A state has the 
following dynamic characteristics: 
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■ number of instances varies, (Train, Anticollision System, Move Con- 
troller and their associated Medium), 

■ instance supports stacks, i.e. push/pop operations that arc passing param- 
eters, insert/remove local variables and the return value of the program 
counter PC, 

■ global binder stores message multisets at the beginning of the state in the 
global area, 

■ local binders store received messages and are attached to each instance, 

■ multisets instance variables store addresses, 

■ messages arc vectors of data which length depend on the message type. 

At the top of the hierarchy, the different components of a BART state appear - in 
the following order: 

■ global variables, 

■ global binder (binder all), 

■ instances, 

■ end of state (special marker). 

All the instances have the same structure shown below: 

■ begin instance (special marker), 

■ local media, 

■ local binder, 

■ instance variables, 

■ program counter (PC), 

■ stack (empty if not within a call), 

■ end of instance marker. 

The structure of the local media is simple: 

■ media id (variable me), 

■ message storage (multiset of vectors), 

■ program counter (PC), 

A block pushed on the stack has the following shape: 

■ parameters, 

■ local variables, 

■ return value of PC. 

The order of the variables and structures has been chosen to save on costly ex- 
plorations of the states. The analysis of data dependencies helps in determining 
the best directions for exploration and thus, the order of the variables as they 
appear in the state. 
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The instances arc grouped by class and arranged into the following order: 

■ instance of Line Manager, 

■ instances of class Train, 

■ instances of class Move Controller, 

■ instances of class Anticollision System, 

■ instance of Operator. 

To each item described above corresponds a part of the state. Building the DDD 
of the state consists in concatenating all the parts together. 

The syntax of the state has been defined to allow easy changes on the order 
of the classes without changing the homomorphisms implementing the model. 
It seems difficult to determine in advance which order will give better perfor- 
mances when computing the reachable states. Some experimentation can help 
determine the best order. 

Note also that there is no order defined within a group of instances of one class. 
The order is difficult to realize because it would depend on values that arc not 
yet known at insertion time. This is not causing a problem in the addition of 
the states because all instances of one class have the same structure. However, 
it may cause some problem with the canonicity of the representation. Solving 
this issue requires implementing reordering homomorphisms, assuming that a 
total order can be found on an heterogeneous structure, which was the case in 
the BART. 

State implementation. Variables of a DDD are identified by an integer 
value. The value of a variable is also of type integer. To help debugging and 
writing efficient homomorphisms, types have been defined. Those types arc 
embedded in the encoding of the variable identifier: 

■ variable (local and global), 

■ program counter {PC), 

■ block of variables, 

■ arrays, 

■ multiset, 

■ binders (local and globals), 

■ media, 

■ instances, 

■ markers. 

The type of variables can be directly tested in the code of the homomorphisms 
using masking operation on the variable identifier. 

The messages are defined by a sequence of assignments as shown on figure 
6.22. The values indicate the length, the destination, the operation code and 
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Length 


Dest 


Opcode 


Params .... 



Figure 6.22. Message structure. 

the parameters of a message. There is no message type defined because the 
messages arc built using the variable of the hosting instance (binder or multiset). 
A number of C++ classes allows to generate DDD for the various types of 
structures. Classes corresponding to each type of instance have been derived 
from the classes listed above. These classes contain explicit list of instance 
variables as they appeal - in the DDD. So, when writing an homomorphism, it 
becomes straightforward to refer to a particular variable. A main class contains 
all the components and allows to generate the whole BART state. 

5.3 Homomorphisms 

The verification of a L/P model by means of DDDs, requires the definition of 
the homomorphisms that represent the L/P operational semantics. We need 
homomorphisms to identify all enabled transitions in order to compute the set 
of new states obtained after the execution of each one of them. 

Basic homomorphisms. A set of basic homomorphisms has been devel- 
opped to manipulate the state. These low level homomorphisms are used to 
implement the transmission of messages, the evaluation of preconditions and 
the firing of transitions. 

To enable communication among the instances, the following homomorphisms 
have been implemented: 

■ binder all to media transfer of messages, 

■ media to local binder transfer of messages, 

■ instances to global binder transfer of messages, 

■ local binder to instance transfer of messages. 

To implement the firing of transitions the following homomorphisms have been 
implemented: 

■ stack operation, 

■ assignments of scalars and arrays, 

■ basic operations on multisets, 

■ assignments using message parameters, 

■ precondition evaluation (expression evaluation). 

Most of the transitions t are implemented by means of two homomorphisms: 
Test _tmnsition(t) will return the DDD containing the states that satisfy the 
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precondition. Fire _transition(t) will return the DDD obtained after firing the 
transition t. 

The computation of the set of reachable states is performed by means of a loop 
that evaluates each transition precondition. We stop to study the execution from 
a set of states if the associated DDD is equal to a one already built. The order in 
which transitions arc studied allows to consider priorities between transitions 
they arc expressed in L/P. 

Precondition evaluation and firing. The state may contain several in- 
stances of a same class. The precondition evaluation homomorphism ( Test - 
transit ion( t )) identifies and marks the eligible instances for a given transition. 
The variable representing the mark is set to 1 if the associated instance satis- 
fies the precondition of the studied transition. If several instances can perform 
the same transition, the homomorphism produces a state for each concerned 
instance with the corresponding mark set to 1. 

The homomorphism that implements the actual tiring of the transition, ( Fire - 
transition(t)), has to find the 1 valued marks and to modify the state in respect 
with the effects of the transition. Such an homomorphism is composed of basic 
homomorphisms as described earlier in 5.3. 

The complexity of precondition evaluation increases when priorities are at- 
tached to transitions. Also the preconditions on theses transitions can depend 
on the presence of a message in the local binder and/or a guard. A guard is a 
logical expression that can depend on global variables and instance variables. 
Composition of operators on homomorphisms can be used to implement selects 
with priorities. The algorithm figure 6.23 shows how to implement them. 



Select (Tl, ... Tn) sorted by decreasing priority: 
currentpriority=priority (Tl) 
test=null 

dddin=input_states 
foreach Ti in (Tl, ... Tn) 

test_i=Test_transition(Ti) (dddin) 
test=test+test_i ; 

result=result+Fire_transition(Ti) (test_i) 
if (priority (Ti)<currentpriority) 
dddin=dddin-test 
currentpriority=priority (Ti) 



Figure 6.23. Computing transition firing from an alternative state with priorities. 

The advantage of this solution is its simplicity. However the cost of the succes- 
sive evaluations of the different transitions that imply multiple explorations of 
the states may be prohibitive in the case of complex alternatives. However, after 
profiling, detection of bottlenecks can help determine which homomorphisms 
need to be optimized. 
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5.4 Example 

This example elaborates the homomorphisms needed to handle the case of the 
beginning of methods start and get_pos in the class Train. These methods can 
be called from state ready and require the reception of a message train.start for 
method start and train.get_pos for method get_pos. Priority of the transition 
b_get_pos (1) is higher then transition b_start (2). 

Based on this example we propose 2 implementations following different strate- 
gies. 

First implementation. The first implementation relies on the algorithm 
proposed in figure 6.23. In this case we just need four homomorphisms. 

■ Precondition evaluation of b_get_pos : filters the states where an instance 
of the class Train is in the state ready , ( PC==ready ) and at least one 
train. get pos message is in the local binder. 

■ Precondition evaluation of b start: filters the states where an instance of 
the class Train is in the state ready , the instance variable Train. s== 0 
(no speed), and at least one train.start message is in the local binder. 

■ Firing of b_get_pos \ this homomorphism takes the output of the precond- 
ition evaluation of b_get_pos as input and apply the following. In the 
case where multiple train, get _pos messages are in the binder, a state 
will be generated for each one of them, and the corresponding message 
is consumed. For each new state, locals of method get pos and return 
value of PC arc pushed on the stack, the PC is set to the next state in the 
get pos method. 

■ Firing of b start, this homomorphism takes the output of the precond- 
ition evaluation of b start In the case where multiple train.start messages 
arc in the binder, a state will be generated for each one of them, and 
the corresponding message is consumed. For each new state, locals of 
method start and return value of PC arc pushed on the stack, the PC is 
set to next state in the start method. 

Then the algorithm in figure 6.23 can be applied to implement the branches. 
The homomorphisms that do precondition evaluation need to be applied twice: 
once to realize the test (Test MransitionfT ) )), and once when composed with the 
firing homomorphism to realize the Fire -transition(Tj) homomorphism. 

Second implementation. The algorithm of transition firing with priorities 
decomposes the input set of states into sets of states that satisfy precondition(s) 
for each priority. This means that the evaluation of preconditions has to be done 
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twice: one to find the states for a given priority in order to substract those states 
from the input set, and one for firing the transitions. 

This second approach implements the whole alternative by means of one homo- 
morphism that takes into account all the priorities of an alternative at the same 
time. As soon as a precondition is invalid, the homomorphism in charge of the 
evaluation must return null in order to invalidate the state under construction. 
The homomorphisms that explore the state create new states and carry on the 
explorations of these new states in search of potential valid preconditions. All 
explorations arc discarded as soon as enough information invalidate the pre- 
condition under study. Invalidating conditions arc : required message is not in 
the local binder, guard is not satisfied, priority is not high enough. 

The following steps show how such an alternative can be realized in 2 explo- 
rations. 

Step 1 : mark all the instances of class Train in the state ready and generate 
states in order to have only one mark set in each new state. This step requires 
the scanning of all the instances of the class Train as the example figure 6.24 
shows. This is a basic homomorphism applied in all precondition evaluation 
cases involving logical expressions. This constitutes the first exploration of the 
whole state. 




t t t 



Figure 6.24. Search for candidate among the train instances. 

Step 2 and 3 are chained and constitute the second pass on the state. 

Step 2: From the output from stepl, explore until finding the local binder of 
the marked instance, unmark the instance, generate a state for each message 
contained in the local binder. The message is attached to the exploration of 
each generated state and is consumed from the local binder. On figure 6.25, 
the example shows a case where two messages arc in the local binder. These 
messages enable the firing of the two considered branches. Guard evaluation 
and priorities arc needed to determine what is (arc) the valid state(s). A state 
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is created for each considered message and the exploration of the local binder 
continues in each new state. Each new state has to be explored from this point 
to determine if it is valid, i.e. if it satisfies all the preconditions. Any message 
that does not satisfy a precondition is not considered. 




Figure 6.25. Exploring the local binder for relevant messages. 

Step 3: This step is directly chained after the end of the exploration of the 
local binder done in step 2. The instance variables arc fetched and guards 
attached to the branches are evaluated. If the evaluation of preconditions with 
the message attached during step 2 is positive and the corresponding branch has 
the highest priority among the other valid branches, then the state is alive and the 
corresponding transition can be fired. If the evaluation of other preconditions 
using the other messages arc of higher priority, then the state is discarded and 
will be removed automatically by returning the null homomorphism. Figure 
6.26 shows the case where all the preconditions arc satisfied. Finally only the 
priorities will decide which state(s) will survive and which one(s) will disappear. 

5.5 Fairness 

In our implementation, the fairness issue is addressed by the algorithm that 
computes the reachable states. In the lfp model of the Bart, the time has no 
representation and reachable states that arc logically correct but physically im- 
possible arc computed. To remedy to this excess of computed states and to 
insure that all the trains arc treated equally, we have decided to separate the set 
of transitions into two sets: 

■ the transitions that involve real time, i.e. the transitions that model a 
physical change of the system, in our case the simultaneous modification 
of the positions of the train. 



the other transitions. 
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End Binder Local 
Begin Instance Variables 



(consumed MSG2) 
=train.get_pos 



-'(consumed MSG1) 
=train. start 



End Instances Variables 
Begin PC and Stack 



K <1 

■■'NULL 



*'■ 



Priority([s==0] && consumed train. start') 

< 

Priority(consumed train, get _pos) 



Figure 6.26. Guard evaluation and destruction of invalid branches. 



This solution avoids the use of a global clock variable, which would cause an 
endless computation of new states. It allows some flexibility on the method 
used to compute the reachable states, whereas the partitionning of the set of 
transition is left to the user. 

The reachable states computation algorithm, will compute all the reachable 
states from the current position of the train and will ignore all transition affecting 
of the physical state of the train. Once all the states have been computed, the 
position modification transitions are examined on the set of accumulated states. 
These transitions are applied as long as new states can be produced. Then, the 
states that reflect the simultaneous update of all trains will be selected for the 
next iteration. This filtering process is critical to avoid the generation of useless 
states considering the position of trains at different time. 

The following algorithm on figure 6.27 depicts the reachable state computation 
with equity. Function Apply All Transition(TSET , STATES, PROGRESS ) ac- 
cumulates in STATES the states produced by applying all transition contained 
in TSET. PROGRESS is set to true if new states are produced. The function 
returns the accumulated states. 

Function Filter(STATES) filters the set of states STATES and retain any state that 
is not intermediate. In the present case, all states that represent a simultaneous 
update of the positions of the trains are kept and returned by the function. 
Additional condition can be added as shown in 5.6 

5.6 Evaluation 

The implementation of the model required the implementation of more than one 
hundred transitions and the elaboration and computation on a state that could 
contain up to (6xf + 4) processes where t is the maximum number of trains. 
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dddin : DDD representing the initial state 

T1 : All transitions except the transitions of T2 

T2 : All transitions updating the position of a train 

NewStates : DDD containning intermediate states computed 

during an iteration 

AccStates : Accumulated states 

NewStates=dddin; 

AccStates=null ; 

while (making_progress) 
making_progress=true ; 

// compute intermediate states 
While (making_progress) { 

NewStates=Apply_All_Transition(Tl , NewStates, making_pr ogress) ; 

} 

01dAccStates=AccStates ; 

AccStates=AccStates+NewStates ; 

making_progress=true ; 

// update position of trains 
While (making_progress) { 

NewStates=Apply_All_Transition(T2, NewStates, making_progress) ; 

} 

AccStates=AccStates+NewStates ; 

// discard all states that do not update all train position 
NewStates=Filter (NewStates) ; 

making_progress=true ; 

if (AccStates==01dAccStates) making_progress=f alse ; 



Figure 6.27. Main loop for state space computation. 



State space computation. The state space computation has been executed 
with different parameters in order to check the impact on the size of the result. 
The experiments were conducted on a 2.2 Giga-hertz Pentium 4 machine with 
5 12M of memory. Two additionnal hypothesis were added to the model in order 
to fit the result in the available memory. 

First hypothesis HI, assumes that all local communication between a media and 
its associated instance are treated before the positions of the trains are updated. 
This allows us to discard cases of late asynchronous notification messages that 
may lead to wrong decisions in the move controller. These specific cases could 
be studied in a separate experiment. This hypothesis is weak in the meaning that 
late messages could be considered as invalid. Included in HI is the following 
assumption : the LineManager only attempts to insert the next train on the 
railroad after and before the updating of the positions. The insertion operation 
takes a short firing sequence that cannot be interlaced with those updates. Again, 
a separate experiment could study the impact of interlacing the train insertion 
and the updating of positions. 
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The second hypothesis H2, is stronger and assumes that in addition to HI, no 
message resides in any storage (binder, media, local binder) when the positions 
of the trains arc updated. This second hypothesis is stronger and restricts the 
number of computed states because it also affects the global binder. It com- 
pletely dissociates the model from the physical representation of the trains and 
generates artificial constraints. The results show the impact of this hypothesis 
even when the size of the global binder is minimal. Including such strong hy- 
pothesis simplifies the model and can help in the debugging process, while still 
covering all the transitions in the model. 

All the execution were using the same railroad and same trains models. The 
physical model was generating 6 positions for the trains and at least 2 cases of 
potential collision detection leading to the processing of emergency situations. 
The following tables summarize some of the experiments done. In all cases 
presented here, all the accumulated states arc stored in memory. The resulting 
DDD represents the reachable states of the system under different hypothesis. 
Column Size Global Binder is the capacity of the global binder. 

Column Size Local Storage is the capacity of local binders and associated media. 
Column Accumulated States is the total number of states. 

Column State max length is the maximum length of the state by means of 
number of variables. 

Column Size DDD ( sharing ) is the size of the DDD representing all the states 
by means of number of nodes. Shared nodes count for 1. Since the sharing is 
enabled by default, this is the number of nodes stored in memory. 

Column Size DDD (no sharing) is the size of the DDD representing all the 
states by means of number of nodes as if states were not sharing identical 
nodes. Comparison with the previous value can give hints on the quality of the 
coding of the state. A good sharing is critical to save memory space. 

Tables shows the impact that binders and media capacities have on the compu- 
tation of state. 

Table 6.1 considers 1 train with hypothesis HI. 

Table 6.2 considers 2 trains with hypothesis H 2. 

Table 6.3 considers 2 trains with hypothesis HI. 

The results suggest that the capacity of the local binder and media have a limited 
impact. The most important parameters arc the number of trains, the hypothesis 
and the capacity of the global binder. Note that the results in 6.3 were limited 
due to lack of memory. 

Some additional testing aiming at evaluating the impact of the cache and the 
garbage collector arc ongoing in order to optimize the DDD library. 

Model debugging with the DDD implementation. Since all the states are 
stored in memory by means of a DDD, properties can be checked by writing 
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Size Global 


Size Local 


Accumulated 


State 


Size DDD 


Size DDD 


time 


Binder 


storage 


States 


max length 


(sharing) 


(no sharing) 


(sec) 


3 


1 


10606 


118 


8343 


250405 


11 


4 


1 


40099 


124 


18872 


853917 


27 


5 


1 


74440 


130 


29222 


1.54e+06 


46 


3 


2 


48237 


121 


10708 


994775 


17 


3 


3 


62068 


121 


11320 


1.25e+06 


21 


3 


4 


63706 


121 


11165 


1.28e+06 


21 



Table 6.1. Impact of binder and media sizes on state space computation, 1 train and HI. 



Size Global 


Size Local 


Accumulated 


State 


Size DDD 


Size DDD 


time 


Binder 


storage 


States 


max length 


(sharing) 


(no sharing) 


(sec) 


3 


1 


286339 


182 


101600 


1.03e+07 


1430 


4 


1 


335827 


182 


122403 


1.24e+07 


1874 


5 


1 


347075 


182 


134551 


1.29e+07 


2099 


3 


2 


363981 


182 


97713 


1.29e+07 


1379 


3 


3 


363981 


182 


97713 


1.29e+07 


1378 


3 


4 


363981 


182 


97713 


1.29e+07 


1379 



Table 6.2. Impact of binder and media sizes on state space computation, 2 trains and H2. 



Size Global 
Binder 


Size Local 
storage 


Accumulated 

States 


State 

max length 


Size DDD 
(sharing) 


Size DDD 
(no sharing) 


time 

(sec) 


3 


1 


2572353 


197 


207273 


7.61e+07 


4023 


3 


2 


50765313 


197 


237542 


1.13e+09 


8152 


3 


3 


53812153 


197 


230360 


1.21e+09 


8313 


3 


4 


53887381 


197 


227043 


1.21e+09 


8283 



Table 6.3. Impact of binder and media sizes on state space computation, 2 trains and HI. 



homomorphisms and apply them on the DDD. Among properties or bug found 
during the implementatio, one can cite: 

■ Minimum resources necessary to cover all the model : reachable states 
computation shown and confirmed that the minimum capacity of the 
global binder was 3. If the capacity is smaller than 3 the model is not 
covered and all transitions are not alive. 

■ Incorrect specifications : the checking of the reachable states shown 
structural bugs in the model, such as dead-lock situations, missing ac- 
knowledge messages and incorrect preconditions. 
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■ Incorrect synchronization : incorrect synchronization specification be- 
tween the media and the instances showed undesired states where the 
addresses of media instances arc released and reassigned before mes- 
sages arc purged from the binders. 

■ Corner cases : many corner cases situations were found using state space 
computations. Among them, we mention : instantiation and destruction 
procedures, initialization of the system. 

We also validate the critical properties presented in section 3.4 using the state 
space generated using DDDs. 

6. Conclusion 

In this chapter, we have shown on the BART case study, the approach taking 
in input a formal specification of a distributed system in the L/P notation and 
computing the state space in order to study properties of the system. The 
technique used to encode the state space relies on DDD. 

This experience has shown that the approach could be automated and that the 
result could be used to validate properties on the systems and to identify bugs 
and potential problems in the specification. 

Even if the DDD library we used for the study presented in this chapter is at 
a beta stage, we got interesting results considering that the modeled system 
contains some difficult elements regarding model checking based approaches: 

■ dynamic instantiation and removal of objects, 

■ complex communication environment involving a dynamic addressing of 
objects, synchronous and asynchronous communications, 

■ numerous interacting tasks, 

■ emulation of high level mechanisms : remote procedure calls, stacks, 
parameter passing, 

■ fairness issues. 

Further work on the DDD library will use this implementation of the hart system 
to evaluate enhancement on the cache and garbage collector implementation. 
The presented approach is of interest because it consider the verification prob- 
lem from the modeling phase, thanks to L/P that offers a reasonable compro- 
mise between standard and formalization. The idea is to provide a notation 
that is closer than the ones engineers arc used to (typically UML;-). This study 
proved that it was possible to model a large and realistic system. Based on this 
experiments, L/P has been chosen as a pivot notation in the MORSE project 
(french-government founded RNTL program) that group together industrials 
partners (Sagem, Aonix) and university laboratories (Labri, LIP6). 
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Mastering the Complexity of Reactive Systems - The AutoFocusApproaeh 



B. Schatz* 



Abstract In this chapter we apply the AutoFocus approach to the BART case study. In 
a nutshell, we investigate how a formally-based approach can help to structure 
the informal requirements, define system boundaries, specify an abstract behav- 
ior of the system and the environment, ensure the suitability of the model, and 
repeatedly enhance the system with design decisions. 



1. Introduction 

The main objective of this chapter is to demonstrate the methodical support 
gained from the application of formal techniques to engineering methods in the 
development of reactive systems. We focus on how the complexity of the design 
process can be reduced by breaking it up into different steps, each concentrating 
on a special aspect of development, and how CASE support can simplify those 
steps. In detail, the following aspects of a formal model-based development 
process will be treated: 

Building models: How to describe system and environment in a systematic, 
manageable, and understandable way. 

Analyze models: How to make sure that the built models arc meaningful and 
meet the stated requirements. 

Improve models: How to increasingly add information to the model to arrive 
at an implementable design. 

In each step, we illustrate the benefits of formal techniques in such a devel- 
opment process. Here, “formal techniques” are understood in a very broad 
sense: 
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Constructive techniques supporting the construction of a system. They range 
from supplying suitable views and description techniques to model a 
system, enabling model transformation techniques, to defining a suitable 
development process for reactive systems. 

Analytical techniques applied to analyze properties of the system under de- 
velopment. They can be either syntactical techniques ensuring a well- 
structured model, or semantical techniques making sure that a system 
meets its requirements. 

In a nutshell, the objective of this chapter is to illustrate how formal methods can 
improve product quality as well as process efficiency by supporting a methodical 
development of reactive systems. The aspects of the BART case study dealt 
with in this chapter using the AutoFocus approach include: 

■ structuring the informal requirements, 

■ defining the system interface including the communicated data, 

■ constructing a model of the environment (trains, train controller) and the 
system (station computer), 

■ analyzing the constructed models concerning conceptual properties en- 
suring soundness of the models, qualitative safety conditions imposed 
on the environment, and quantitative safety conditions imposed on the 
system (MTTH), 

■ defining an architectural partitioning (VSC/NVSC components), 

■ refining the reactive behavior of the system including respecting acceler- 
ation by graded tracks, and avoiding mode change. 

2. Technical Approach and Method 

Instead of giving an in-depth description of the AutoFocus tool, we focus on 
the methodology behind it. Therefore, in the following subsections we give a 
short introduction to: 

Modelling Reactive Systems: Basic concepts used to model reactive systems 
and their relations, corresponding description techniques, and their inter- 
pretation. 

Model-Based Development: Constructive and analytical techniques applica- 
ble to those models, and their integration in a development process. 

For more detailed information on the tool aspects of AutoFocus we refer to 
appropriate information in each subsection. 




AlltoFoCUS - Mastering the Complexity 217 

2.1 Modelling Reactive Systems 

Since we use the AlltoFoCUS description techniques in the remainder of this 
chapter, we give a short introduction to its modelling approach, being as general 
as possible. Therefore we define: 

■ what building blocks arc needed to build a specification, 

■ how those building blocks arc combined to describe a system, 

■ and, how such a description is interpreted. 

These issues will be discussed in the following subsections. 

Modelling Concepts for Distributed Systems. Independent of how we 
represent a specification of an embedded system, we can identify some basic 
concepts characterizing such systems. Subsequently, we briefly describe the 
conceptual elements that make up our view of a distributed system. 

Components arc units encapsulating data, structure, and behavior, communi- 
cating with their environment. They arc reactive and respond to stimuli 
from the environment. Components can be hierarchically structured, i.e., 
consist of a set of communicating sub-components. 

Types define data structures and functions used by components. 

Data arc encapsulated by a component and provide a means to store persis- 
tent state information inside a component. They arc realized by typed 
variables. 

Channels define the communication structure, i.e. the topology, of a dis- 
tributed system by connecting components via ports. They arc directed, 
named, and typed. 

Control States and Transitions between them define interactions of a com- 
ponent by describing what messages are produced and how the state is 
changed, depending on the current control and data state as well as the 
messages received. 

Events describe instances of those interactions, i.e. a specific message ex- 
changed or state changed. 

Event sequences arc sequences of such events describing an execution sce- 
nario. 

These elements form the basis of AlltoFoCUS description techniques; the re- 
lations between them arc described in the conceptual model; their exact inter- 
pretation is formalized in the semantical model. 
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Views and Notations: Description Techniques. AutoFocus offers 4 
hierarchically structured description techniques to form a comprehensive and 
structured picture of a system, described from different points of view and on 
different levels of abstraction: 

■ system structure diagrams (SSDs), 

■ data type definitions (DTDs), 

■ state transition diagrams (STDs), 

■ and, extended event traces (EETs), 

each one covering different — yet not necessarily disjoint — aspects of the 
system. The integration of the views on a common semantic basis leads to one 
formal specification of the system. 

AutoFocus supports hierarchical development of systems. Depending on the 
granularity, views (e.g. SSDs) can be atomic, or consist of sub-views them- 
selves (e.g. SSDs assigned to components in an SSD). Therefore, AutoFocus 
allows to switch between different levels of granularity by using the hierarchical 
description techniques described in the following subsections. 

For easier understanding, the diagrams in those subsections describe a pedes- 
trian traffic lights system. 

System Structure Diagrams (SSDs). A (distributed) system consists of 
its components and the communication channels between them. To describe 
the architectural aspects of distributed systems, viewing it as a network of 
interconnected components exchanging messages over channels, we use system 
structure diagrams. Graphically, SSDs, as shown in Figure 7.1, arc similar to 
data flow diagrams, with components, channels, and ports. 

Each component has a name and a set of input and output channels attached to 
it via input and output ports. Every channel is defined by a channel name and 
the set of messages that may be sent on it. In case no value is sent, the channel 
contains a default nil-value. Thus SSDs provide both the topological view of a 
distributed system and the signature of each individual component. 

Since each component can be described as distributed system in itself by as- 
signing an SSD to it, hierarchical system descriptions can be specified. Here, 
ports arc used for modular descriptions: a port attached to a component will 
also be present in the inside view of this component, i.e., the assigned SSD. 
Thus visible from the inside and the outside, ports serve as interface between 
the environment of a component and its internal structure. 

In AutoFocus components in an SSD can be associated with substructures 
(SSDs), behavioral views (STDs or EETs), and component data declarations 
(CDDs). A component data declaration declares local variables for the compo- 
nent by setting a name and a data type for each variable. These variables arc 
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Figure 7.1. A Sample System Structure Di- Figure 7.2. A Sample Extended Event Trace 
agram. Diagram. 

used to define the behavior of a component by characterizing the data space of 
the component. 

Data Type Definitions (DTDs). In AlltoFoCUS, the types of the data 
processed by a distributed system are defined using textual notations called data 
type definitions. The functional variant - based on concepts found in languages 
like Gofer [Jon93] - is used to declare new types and functions operating on 
them. To define, e.g. a valiant message record type holding a PIN or an abort 
signal, we write 

data Message = Msg(PIN:Int) | Abort; 

While in functional languages generally PIN(m) is used to access the record 
element of a variable M of this type, we will also write m . PIN for easier reading. 
Data types arc, e.g. used to declare local component variables (see above) or 
types of communication channels. 

State Transition Diagrams (STDs). An STD characterizes the behavior of 
a system or component, which is reacting to input received from its environment 
by producing output sent to the environment, depending on the its current state 
and setting a new state. Because an STD describes an extended finite state 
machine using variables local to the characterized component, the state of a 
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Figure 7.3. A Sample State Transition Diagram. 

component is defined both by the control state (the state of the finite state 
machine) and the data state (values of the local variables) of the component. 
STDs arc represented by graphs with labelled nodes as states and labelled arrows 
as transitions. Figure 7.3 shows a simple example with one transition annotation 
in the detailed view. 

Each system component of an SSD can be associated with an STD. Just as 
with SSDs, each state of an STD can be decomposed into an STD of its own. 
Transitions arc characterized by the following annotations: 

■ pre- and post-conditions (e.g. t==-l, and t=TGreen, resp.) which arc 
basically predicates over the local data state of the component as described 
by its local data definition, 

■ a set of input and output patterns describing the messages that arc read 
from or written to the input and output ports of the component (e.g. 
Req?Present, and TL ! Green, resp.) and 

■ an optional label, to complement the otherwise used conditions and pat- 
terns for better readability (e.g. Receive Request). 

For hierarchical decomposition of states in STDs, we use a concept similar 
to the one used in the SSDs. The treatment of substructures in STDs and 
SSDs is similar: for every edge (transition/channel) into or from the node 
(component/state) a connector or port is created both at the node and in the 
substructure. 
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Extended Event Traces (EETs). Aside from STDs, extended event traces 
may also be used to describe the behavior of distributed systems. EETs (see 
Figure 7.2) define a component- and communication-oriented view, describ- 
ing system behavior by sample communication histories between components. 
AutoFocus uses a subset of notational elements of the Message-Sequence 
Chart standard [IT96], similar to the concepts used in UML [FS97]. As well 
as other graphical AutoFocus notations, EETs support hierarchical concepts. 
Boxes can be used to reference a set of sub-EETs. These means of structuring 
also allow the introduction of valiants of behavior. Additionally, indicators can 
be used to define optional or repeatable subparts of an EET (e.g. 0-*). Finally, 
state annotations can be used to refer to local variables of the components. 
EETs can be used at different development stages for different purposes: in 
early stages of system development to specify elementary functionality or error 
cases by examples, later in the development process, the system specifications 
given by SSDs, STDs, and DTDs can be checked against the EETs, whether 
the system fulfills the properties specified in them, and during validation EETs 
can be used to visualize simulation results, or error paths, e.g. obtained from 
model checking the system. 

Interpretation. In AutoFocus, a system is described as network of com- 
ponents, communicating via directed, unbuffered channels. Communication 
takes place in a clocked manner, each component sending out messages over its 
output ports (or sending an implicit nil, if no explicit message is present) and 
receiving messages over its input channels. The behavior of each component 
is defined by its associated STD. If a component has a hierarchical structure 
defined by an SSD, the behavior of this component is defined by the combined 
behavior of its subcomponents. 

An STD characterizes the behavior of a system or component as an extended 
finite state machine; input and output patterns are used to describe the messages 
read from the input ports and written to the output ports. An input pattern is 
a pair of an input port name and a constructor pattern over the component’s 
local variables and over free variables for the transition. An input port pattern 
matches an actual message at this port, if the constants and the values of the 
defined variables match the corresponding values of the read message. The free 
variables arc bound to the actual values as found in the message. Thus, while 
the local variables of a component arc only checked in an input pattern, the free 
variables get set during the matching process. Output patterns arc pairs of port 
names and expressions. In output patterns, defined and free variables arc bound 
to their current values. In post-conditions, for each defined variable x a primed 
variable x' can be used to address the value of the variable after the execution 
of the transition (we use x = v instead of x' == v as a shorthand notation). 
It is important to note that in our approach the input is read simultaneously 
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from all input ports. In the simulation semantics, input patterns used in an STD 
arc interpreted to be complete in the sense that unspecified combinations of 
input patterns arc interpreted to result in an empty- valued output and leave both 
control state and local variables unchanged. 

An EET description of a system behavior is interpreted as concurrent runs of its 
components, each component represented by a corresponding axis. Each run 
is described by the events caused by incoming and outgoing messages of the 
component. Events occur in the order as described along the axis. Messages 
arc defined using analogue patterns used in STDs. By linking the sending and 
the receiving events of a message, those single descriptions arc combined into 
a complete system description. The transmission of a message between com- 
ponents is interpreted to happen instantaneously, no delay is introduced during 
transmission. In the untimed version, arbitrary delays may occur between 2 
events along an axis. To add timing aspects to an execution, ticks in form 
of dashed lines can be used to mark one round of communication. Events in 
between ticks occur during the same round. 

Besides describing the meaning of the sequences of interactions within one 
EETs, we also add an intended interpretation for a combination of EETs; e.g. 
by declaring it as universal (i.e., each behavior of the system is captured by 
the set), existential (i.e., the system can perform the behavior as described 
by the diagrams), negation (i.e., the described behavior may not occur), or 
combinations thereof. 

On the basis of this interpretation for its description techniques, AutoFocus 
offers facilities to: 

■ run the system in a simulation environment and visualize the runs using 
the AutoFocus description of the system, 

■ generate test cases for an implementation of the system, 

■ generate executable code of (a paid of) the system, and 

■ generate specifications to be analyzed using model checkers or interactive 
theorem pro vers. 

For a more detailed description of these facilities see [BLSSOO] or [SPHP02]. 

2.2 Views and Models, Consistency Conditions, and 
Model Based Process 

After introducing the concepts and techniques used to describe reactive sys- 
tems, we now take a short look at the corresponding methodical principles and 
development process supplied by the AutoFocus approach, by looking at the 
views and models behind AutoFocus, consistency as the linking element dur- 
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Figure 7.4. Simplified Conceptual Model. 



ing the construction of models, and finally the principles of the AlltoFoCUS 
development process. 

Views and Models. Developers create and manipulate models - of the 
system under development as well as the environment controlled by the system 
- by means of description techniques. These techniques (e.g. STDs or EETs, as 
described in the previous sections) provide views upon these models, possibly 
even different views on the same parts of the model: e.g. an EET including a 
scenario description of a component, and an STD, which describes the complete 
behavior of the component. In Section 4 we define several of those views of 
the AATC in form of SSDs, STDs, EETs, or DTDs. 

In Subsection 2. 1 we introduced the elements that arc used to build a description 
or view of the system. To describe how those elements arc related ‘syntacti- 
cally’, we use the conceptual model. Si mi lar to a UML meta model, it defines 
the “abstract syntax” of the information given by the notations used. Figure 7.4 
shows a simplified version of the AlltoFoCUS conceptual model, linking the 
conceptual elements introduced in Subsection 2. 1 . A more detailed description 
of the modeling concepts and the conceptual model can be found in [BLSSOO]. 
The conceptual model ensures that all views that arc constructed as an instance 
of it arc “well-formed” and fit together, as described in the following subsection. 
Besides making sure that the views of a system arc conceptually well-formed, 
we also want to make sure that they fit together semantically. Here, the seman- 
tical model is used as the formalization of the interpretation of the diagrams, 
as introduced in Subsection . It defines the semantics of a set of views and is 
therefore used as the basis for the generation of simulations, code, test cases, 
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or specifications to be verified by proof tools. Si mi lar to the conceptual model, 
it is also used to ensure that the views of a system fit together semantically, as 
described in the following subsection, too. 

Consistency Conditions. While views arc introduced to reduce the com- 
plexity of a system during its construction by braking it up into manageable 
parts, consistency is used to make sure that those parts fit together to form a 
suitable model. Since we have 2 kinds of “meta models” guiding the develop- 
ment process, we have 2 corresponding classes of consistency conditions: 

Conceptual consistency conditions. These conditions can be expressed com- 
pletely within the conceptual model. They either hold invariantly by 
construction, or can be relaxed during certain steps of the development 
process and arc enforced during others. 

Semantic consistency conditions. These conditions arc expressed using the 
semantical model; their validity is either ensured by construction or 
checked at defined steps of the process. 

In general, conceptual consistency is a prerequisite to semantic consistency or 
constructive techniques. 

Conceptual Consistency Conditions. Since AutoFocus (like most graphic 
modeling tools) extensively use views, it important to make sure that the in- 
formation spread out over several views is well-defined or “consistent” in a 
methodological sense. Two forms arc offered: 

Invariant conceptual consistency conditions. Syntactic consistency condi- 
tions that must always hold in a model, like “A channel always connects 
two ports” or “Transitions only use ports of the corresponding compo- 
nent”. 

Variant conceptual consistency conditions. Methodical consistency condi- 
tions that most hold in a sound model but may be relaxed in between, like 
“An initial hierarchical state has at least one initial sub-state” or “All tran- 
sitions leaving a state have disjoint patterns thus ensuring deterministic 
behavior”. 

Invariant conditions arc “built” into the conceptual model. Since AutoFocus 
uses description techniques as the visual representation of instances of the con- 
ceptual model, these conditions arc therefore ensured by construction when 
building a model of the system or the environment. In contrast, variable condi- 
tions must be actively invoked by the user. In the AutoFocus approach we use 
CCL (Consistency Constraint Language) to define valiant conditions. Similar 
to the OCL, it corresponds to a first order calculus with the types (classes) and 
relations (associations) of the conceptual model. AutoFocus offers an eval- 
uation mechanism for CCL expressions returning all counterexamples of the 
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current instance of the conceptual model. For example, the following consis- 
tency condition ensures that a super state of an initial state is also initial. 

forall s: State, is Initial (s) implies 

(forall sup: State, (is Superstate (sup , s) 
implies is Initial(sup) ) ) 

The decision to fix a conceptual consistency condition as either invariant or 
valiant influences the development process: more valiant conditions increase 
flexibility, more invariant conditions increase rigorousness of the development 
process supported by the underlying model. 

Semantical Consistency Conditions. According to the the AlltoFoCUS 
description techniques shown in Subsection , two forms of semantic inconsis- 
tencies can occur between the introduced views: 

Inconsistencies of scenarios. Scenarios of a system as described by EETs can- 
not be executed by the realization of the system as described by SSDs 
and STDs. Furthermore, since - in an extreme case - complete behavior 
can be defined by a set of EETs, even a set of EETs can be inconsistent, 
making it impossible to be implemented. 

Inconsistency of refinement. Using AlltoFoCUS, behavior of a component 
can be defined in two different ways: either by defining an STD for 
the components, or by defining a set of sub-components and adding an 
STD to each of them. Then, an inconsistency occurs if the network of 
sub-components can exhibit some behavior that is not possible with the 
abstract component. 

To check for inconsistencies of scenarios or refinement, AlltoFoCUS offers a 
connection to different proof tools (e.g. pcke). Besides using these semanti- 
cal consistency conditions, of course general temporal logic properties can be 
checked against the system descriptions using symbolic model checkers (e.g. 
SATO, SMV). Since detailed system descriptions arc often too complex to be 
handled by symbolic model checking, also explicit model checking techniques 
as well as connections to interactive theorem provers (e.g. VSE, Isabelle, STeP) 
are available (see, e.g., [BLSSOO]). 

Views, Consistency and Process. In the model-based approach, each view 
of the system contains part of the information needed to define a complete model 
of the system. All views together form the model. Each view is an instance of (a 
part of) the conceptual model. Additionally, all views must eventually respect 
further consistency conditions (defined upon the conceptual or the semantical 
model) to form a reasonable model. By decreasing/increasing the complexity 
of the conceptual and semantical model and making consistency conditions 
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variant/invariant, the flexibility/rigidness of the development process can be 
defined. By over-simplifying the conceptual and semantical model, we end up 
with a graphical programming tool. By abandoning too many conditions, we 
end up with a mere drawing tool. 

Using consistent views of a model of the system as “building blocks”, the model- 
based development process can be seen as the construction of increasingly 
detailed views of the system under development resulting, from the very abstract 
requirements to the implementation level. Inherently associated with CASE 
support, it offers: 

Improved Quality. By using concepts taken from the domain of application 
(e.g. message, state, event), we obtain a domain-specific model of the sys- 
tem under development, avoiding to overlook errors by an implementation- 
biased view or even introducing artificial ones. Furthermore, by assign- 
ing an interpretation to all views, even views already at an early stage 
of the development can be analyzed for defects. Finally, by integrating 
all views into a common model, those abstract views are ensured to fit 
together with their more detailed counterparts. 

Improved Efficiency:. Automatic and interactive support for establishing the 
consistency conditions enables an early detection of errors in the con- 
structed models, reducing the need for changes due to late detection. 
Furthermore, out of the model the system, e.g. simulations, code, or 
test cases can be generated. Finally, complex transformations, e.g., the 
insertion of a protocol driver, or reuse of specification parts, can be me- 
chanically supported. 

For full usefulness, a model-based process must by tuned toward its applica- 
tion domain. The approach presented here addresses aspects of reactive sys- 
tems; additional aspects relevant for deeply embedded systems, e.g. lengths 
of computation tasks or communication schedules, arc currently added to the 
AutoFocus conceptual and semantical model. 

3. Inputs taken from the BART case study 

To demonstrate the AutoFocus methodology throughout the development pro- 
cess, we cover most requirements of the informal specification of the BART 
system, including architectural requirements (VSC/NVSC issues), qualitative 
and quantitative safety requirements, and performance optimizations. However, 
we make several simplifying assumptions to make the approach presentable 
without reducing the basic complexity of the system : 

Safety aspect. In the following we will only consider the problem of avoiding 
to hit a leading train; for the sake of brevity, the treatment of gates or 
maximum allowable civil speed is ignored. 
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Reliability of the environment. For the communication network, we assume 
the transmission delay introduced is bounded, so that a command message 
sent from the station controller during a 0.5 second cycle will also be 
received during this cycle while the network is operational. This can be 
ensured using, e.g. a time triggered protocol. 

Timed execution. To simplify the internalized model, we assume that the train 
controller has an execution cycle (reporting status, issuing commands to 
the train) of 0.5 sec. 

Reported values. For minor simplification, the positioning algorithm gener- 
ates only an position and velocity estimate (instead of corresponding 
means and deviations). 

Physical model. To simplify the description of the environment, the command 
calculation and the proof of the safety condition, the effect of slopes on 
trains is ignored. Furthermore, to simplify the treatment of braking, we 
assume only closed loop braking is used. 

4. Applying the approach to the case study 

After having introduced the AlltoFoCUS approach in Section 2, in this section 
we illustrate its application using the BART case study. The development of 
the control system is split up into steps, each illustrating how a model-based 
approach helps: 

Step 1 : to structure informal requirements and to reduce their complexity. 

Step 2: to get a clear understanding of the system boundaries and to make 
implicit assumptions about the environment explicit. 

Step 3 : to define an abstract system behavior without limiting the design space 
for possible implementations. 

Step 4: to check the soundness of the constructed models. 

Step 5 : to establish the qualitative and quantitative properties required to hold 
for the BART system. 

Step 6: to support design decisions concerning the structure of the system. 

Step 7 : to support design decisions concerning underspecified behavior of the 
system. 

Step 8 : to increasing robustness by considering undefined behavior. 

In a (classical) software development process, these steps are generally asso- 
ciated with development phases like Requirement Analysis (Steps 1, 2, and 4), 
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Early (Steps 3 through 5), and Late Design (Steps 6 trough 8). Of course, the 
presented steps arc neither complete (e.g. the construction of a simulation or 
the generation of deployment code is not included) nor presented in full detail 
(e.g. only some of the associated requirements arc listed in Step 1, the property 
investigated in Step 5 is restricted to the collision problem). For an extensive 
treatment of aspects like the construction of simulations or deployment code, or 
the application of verification tools the reader is referred to the literature cited 
in Section 2 or to approaches introduced in the previous chapters. 

4.1 Step 1: Structuring the Requirements 

In the first step, the informal requirements as described in Section 1 are broken 
up into coherent parts (consisting of one or several sentences). Each of those 
coherent parts is then associated with a conceptual element. The purpose of 
this structuring step is threefold: 

■ to reduce the complexity of the informal specification by breaking it up 
in smaller, coherent parts, 

■ to bridge the gap between an informal and a more formal specification of 
the requirements by linking those coherent parts to conceptual elements, 

■ to support the development process by coverage analysis or by traceability 
of this linking. 

As shown in Figure 7.4, typical conceptual elements used to model reactive 
systems arc component , data type, variable, state, and transition. Accordingly, 
when structuring the informal specification and linking it to the conceptual 
model, examples of this correspondence arc: 

Component. Requirements stating the existence of a hardware or software 
component, e.g. in Par. 19: “The station computer itself is divided into 
two systems. First is the Non- Vital Station Computer (NVSC). Second 
is the Vital Station Computer (VSC).” 

Data type. Requirements stating the use of a certain form of data for com- 
munication or processing, e.g. in Par. 27: “The control algorithm (. . .) 
message contains (...) ID of the train (...), commanded speed (...), 
commanded acceleration (...), Message Origination Time Tag (. . . ).” 

Local Data. Requirements stating which data is locally available for defining 
the behavior of a system or component, e.g. in Par. 25: “The following 
static data is also available for segments of the track: segment location, 
grade, maximum allowable speed, location of gates.” 
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Figure 7.5. Linking Informal Requirements to the Model 



Event. Requirements stating actions of a component, e.g., in Par. 27: “Each 
half-second the station computer receives ranging- and speed informa- 
tion. The control algorithm must then produce for each train a command 
message.” 

As shown in Figure 7.5, AlltoFoCUS integrates the requirements into the devel- 
opment process by making the requirements part of the model and supporting 
links between the informal requirements and the conceptual elements. By es- 
tablishing a link between the informal description and the conceptual elements 
introduced in the following steps, domain-oriented tracing of requirements is 
possible; e.g. when introducing the state Collect Data as part of the abstract 
behavior of the speed controller in Step 3 in Section 4.3, the above state re- 
quirement is associated to the state as a justification for this design decision. 
Furthermore, during the development process, we can check for the number of 
uncovered requirements; e.g. before introducing the structural refinement of 
the Station Computer in Step 4.6, the above component requirement is not yet 
accounted for. 

4.2 Step 2: Dealing with System and Environment 

After structuring the informal specification and linking it to modeling concepts, 
in the next step we develop a precise description of the environment of the 
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system under development and its interface to the system. The model of the 
environment is used to: 

■ explicitly represent the state of the environment. Using this state, we can 
express properties about the parts of the environment we are interested 
in (like the position and the speed of the trains) rather than state of the 
system or the interface between them (like estimated position and the 
commanded speed). 

■ formalize assumptions about the behavior of the environment of the sys- 
tem. Using this explicit formalization of the relation between the state of 
the environment and the interface we can validate whether we have a suit- 
able model of the environment, e.g. by comparing simulations to actual 
measurements or verifying properties of the environment (e.g. that the 
physical model of the train does not allow negative speeds). Furthermore 
we make assumptions explicit which arc needed to establish the required 
behavior of the system (e.g. that the brake rate of the brake system has a 
lower bound). 

The model of the environment is built by defining: 

Environment variables: the variables of the environment we want to monitor 
or control (e.g. the actual position, speed, and acceleration of trains). 

Interface variables: the variables of the interface between system and envi- 
ronment we can read or write (e.g. the estimated position and speed, the 
commanded speed and acceleration). 

Environmental assumptions: the relations between the variables of the en- 
vironment (e.g. differential equations describing the laws of physics of 
the train, or timeouts of the train controller triggering the fail safe mode). 

Interface relation: the relations between the environmental and interface va- 
riables (e.g. the transformation of physical position and speed to the train 
into the estimated position and speed). 

Since dealing with implicit assumption is, as stated, e.g. in [Jac96], a common 
source of errors, approaches dealing with embedded systems should make these 
assumptions about the environment explicit; SCR [Hei02], e.g. uses the 4- 
variable model of [PM95] to explicitly model the environment. As shown in 
Figure 7.6, in the AutoFocus approach, system and environment arc modelled 
in form of a control loop, with input read from the environment and output fed 
to the environment; the environment, like the system, can be structured into 
state-based subcomponent with local variables. Figure 7.6 shows that in our 
case the environment contains additional software parts (e.g. Positioning 
System), and hardware (e.g. Communication Network) besides the train. 
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Figure 7.6. Structure of the BART System, Environment, Train 



The train, again consists of a TrainController (assuming only one AATC) 
and a TrainModel (describing the train physics). 

Introducing the interface makes some implicit assumptions explicit in this step, 
e.g. that communication between the system and the environment is taking 
place in a sequential manner (one message at a time, one command at a time). 
Additionally, using the model based approach, some basic conceptual consis- 
tency conditions, e.g. the consistency between the internal and external view 
of the environment, are ensured by construction. 

The local data of the environment forms the environmental variables. Typically 
for embedded systems, the environment consists of hardware parts (like the 
mechanical part of a train) as well as a software parts (like the train controller 
or the position algorithm), as shown in Figure 7.6. While the hardware parts 
generally have continuous variables and a continuous behavior, software parts 
use discrete variables and behavior. Here, the environmental variables of the 
physical model of the train (TrainModel) include the continuous variables for 
position (pos), speed (vel), acceleration (acc) for each train; they also include a 
timer (Timer) to describe the mode change delays. The discrete environmental 
variables of the controller of the train (TrainController) include the current 
valid MOTT (tag), a local clock (clock), and a timer for the generation of 
status reports (Timer). Additionally, the messages exchanged between the 
components of the environment are paid of the environmental variables, too. 
These include the channel for the acceleration commanded by the controller 
(CAcc) as well as position and speed as recorded by the controller (SPos, SVel). 
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Figure 7.7. Behavior of TrainController 



Similarly, the interface variables can be identified by locating the channels 
between the system and the environment. Here, the interface variables arc 
defined by the channel for the command messages from the system to the 
environment (Cmd) as well as the channel for the reports of the positioning 
system (Rep). To define the environment variables as well as interface, we also 
have to define the types of those variables. Again, we make use of the structured 
requirements of the previous step classified as data type requirements. As a 
result, part of the message types of the interface channels or internal channels 
arc defined by: 

Command = Cmd (Cld: ID, CMOTT : Time ,CVel : Float , CAcc : Float) ; 
Report = Rep (Rid: ID ,RM0TT : Time ,RPos : Float ,RVel : Float) | 

Gt (GId : ID , GState : GStatus) ; 

Status = St (SMOTT : Time , SPos : Float ,SVel : Float) ; 

The next step in constructing the model of the environment consists in assigning 
behavior to all components of the environment. The state-transition diagrams 
of AutoF OCUS can be used to model a hybrid environment consisting of contin- 
uous parts like the train model as well as discrete parts like the train controller, 
as shown in the following. As mentioned above, the AutoFocus approach tar- 
gets the description of reactive systems and therefore uses clocked models. To 
model the environment, we will extend the AutoFocus approach with a sim- 
ple linear time model (see, e.g. [MSOO]) to support the treatment of continuous 
behavior. 

To define the train controller, we assign a standard AutoFocus STD to the 
TrainController component. As shown in Figure 7.7, it consists of 2 states 
(Normal, FailSaf e) for normal and fail safe operation and uses a cycle time of 1 
ms. During normal operation, every 500 ms a status report is generated; further- 
more, as defined in the expanded transition with label Status and Command a 
command received in time before fail safe mode is executed with the beginning 
of a new cycle as long as the command is valid: 
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Figure 7.8. Behavior of TrainModel 

Precondition (Timer==0) && ( (tag+2000) >clock) stating that a new cycle 
begins with the failsafe timeout not yet occurred. 

Input Cmd?Cmd(id,tag,cvel,cacc) ; SPos?spos ; SVel?svel stating that 
a new commanded message was received with the new MOTT tag and 
new command speed and acceleration (cvel.cacc), as well as the current 
status (spos, svel) of the train. 

Output St ! St (id, clock, spos , svel) ; CAcc ! adjust_acc (svel , cvel , 
cacc) stating that a report is generated and the adjusted acceleration 
command is set to be executed by the train. 

Postcondition Timer=499 ; clock=clock+l ; tag=ctag; vel=cvel ; acc= 
cacc stating that a new 500m5' round is stalled while the local clock is 
advanced; additionally, the command is stored. 

Function adjust acc limits the commanded acceleration of a train dependent 
on the current and commanded speed, as described in Par. 29 and Par. 30. 

As mentioned above, STDs can also be used to model the continuous paid of 
the environment. However, here the interpretation differs from STDs for dis- 
crete components. While a discrete component performs its computation (and 
the corresponding execution of transitions) only once each cycle, a continuous 
component has no discretized behavior. Therefore, additional to the transitions, 
behavior for continuous components can be defined using activities. Activities 
arc assigned to states and arc preformed continuously (while the guard is sat- 
isfied) until a transition is executed for this state. Consequently, activities arc 
used to describe a state of a system, where the system behaves continuously. 
Generally, differential equations arc used to describe the invariant condition. 
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Figure 7.9. Behavior of the Propulsion State 



which holds while the component remains in this state. Figure 7.8 shows the 
STD describing the behavior of the train model component TrainModel with 
4 states characterizing different continuous behavior with the corresponding 
activities describing the invariance conditions: 

Engaging Brakes, Engaging Propulsion: both with activity 

Timer < l:vel = Deriv(pos) ;acc = Deriv(vel) ; acc = 0; 

Propulsion: with a behavior defined by the STD of Figure 7.9. 

Braking: with a behavior defined by an STD similar to Propulsion with 
sub-states for High and Low braking and corresponding intermediate 
states JerkUp and JerkDown. 

Transitions like Reconfigure are defined using enabling conditions (acc == 
0) and assignments (Timer = 1); the execution of a transition is assumed 
to take no time. To formalize the semantics of the hybrid environment, hybrid 
transition systems (e.g. [MP95]) are used. Flybrid transition system differ from 
discrete transition systems (as used in AutoFocus to model discrete behaviors) 
by supporting continuous variables, i.e. variables that change continuously over 
time. Here, we use continuous variables for the variables of the environment 
(e.g., pos, vel) and the clocks describing delays (Timer). Additionally, a 
continuous variable T G T is used to describe the physical time. To describe 
the system state, a variable state is used. Using this formalization scheme, 
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state = Braking A acc = OA 

state' = Engaging Propulsion A Timer 7 = 0AT = T' 

using primed variables (e.g., state') to describe the post state. Accordingly, e.g., 
the invariant of state Engaging Propulsion is expressed as a transition with 

(Vr.O < r < tick => Timer + r < 1)A 
T' = T + tick A Timer 7 = Timer + tick A 

pos 7 = pos + J^ ck vel dt A vel 7 = vel + J^' ck acc dt A acc = 0 

Since this formalization corresponds to the semantics used with the temporal 
theorem prover STeP [BBC + 97], in Subsection 4.4 we will use STeP to ver- 
ify safety requirements. To formalize a standard AlltoFoCUS component in 
this framework, a timer Cycle for the execution cycle time is added to exe- 
cute transitions at the cycle time and ensure keeping of the variables between 
transitions. 

Note that in the model of the environment we do not only describe its non-faulty 
behavior. Since we are interested in building a reliable station computer, we 
also describe possible faults in the environment we want to compensate. For 
example, to comply with the requirements stated in Par. 18, we can define a 
communication network that regularly will ensure reliable communication but 
may stop to transmit messages at any time. Making assumptions about the 
environment explicit, certain faulty behavior can be excluded. In case of the 
communication, e.g. we can exclude the behavior that the network occasionally 
drops a message. 

After adding the environmental model, we can now formulate more extended 
qualitative safety properties dealing with the state of the environment, as ,e.g. 
in the requirement Par. 38: “One fundamental safety requirement is that train 
speeds and accelerations be selected so that (...) the train does not hit a train 
in front of it (. . . ).” While this property can be also expressed as an EET, 
most naturally this requirement is defined as temporal property with variables 
depending on a time point r G T stating 

Vr G T. Vfi, t -2 G Trains. t\.pos T + Nose / t 2 -pos r — Tail (7.1) 

(with Nose and Tail describing the length from the position of a train to its nose 
and its end, resp.). This property describes a typical form of safety requirements: 
stating that the environment is always in a safe state. Here, a state is considered 
safe if no train is hitting another train. In Subsection 4.5 we will show how 
such properties are established. 
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Figure 7.10. Overall Behavior. 



Figure 7.11. Instance of Messages. 



4.3 Step 3: Defining the Abstract Behavior 

To define the behavior of a the System component introduced in Subsection 
4.2, we use the state -based and the interaction-based descriptions formalisms of 
AutoFocus. For the description of the station computer, we identify the overall 
behavior of the system, define the computations performed during each step , 
define the data state of the controller by defining its local variables, and finally 
define the control state and transitions triggered by input from the environment 
and producing output. 

To describe the overall behavior of the System component, we look at all the 
information about corresponding events collected in Step 1. We use the interac- 
tion view in from of the EET of Figure 7.10 describing that the behavior basically 
consists of 2 phases (described by the boxes Messages and Commands ) which 
arc cyclically repeated. It states that the duration of a communication cycle, 
consisting of receiving the status (and some hand-shake) data, calculating the 
commands, and issuing the commands is 500 ms. Figure 7.11 shows a possible 
instance of the first phase, stating that in the receiving phase no command is 
produced. This interaction description does already incorporate design deci- 
sions of the communication protocol and removes ambiguities of the informal 
specification: it is split in 2 phases such that commands arc only sent after all 
status messages arc received. Note that this description of the timing aspects 
of the behavior can also be interpreted as a requirement of the behavior of the 
environment: assuming universal interpretation, the EETs states that 
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■ each cycle has a length of 0.5 seconds, 

■ and, part of each cycle consists of the collection of messages, a phase 
which is in complete control of the environment. 

Therefore, an implicit assumption is made about the Environment: the envi- 
ronment must produce the messages sufficiently fast in order to let the controller 
meet the 0.5 second deadline. The explicit treatment of those requirements is 
already covered by the modelling of the environment in Step 2 and will be 
needed in Step 5 to establish the requirements. However, for a sound design, 
conceptual analysis performed in Step 8 in Subsection 4.8 will make it necessary 
to decide what to do in case of late signals. 

While the description of the overall behavior can easily be derived from the 
informal requirements, the definitions of the computations performed during 
each step arc less easy to obtain, even given the description of worst case 
stopping distances in Par. 38. To define the computations, we first must define 
what information is used in these computations. As already seen during the 
formalization behavior of the environment in Subsection 4.2, the worst case 
stopping distance of a train depends on the behavior of the train during the 
fail safe brake mode. The most influential factor is the state the train is in at 
the beginning of the stopping profile. Obviously, the distance is longest if the 
train is in full acceleration at high speed, and shortest, if the train is already in 
maximum braking mode. Consequently, to avoid excessive stopping distances, 
the current state of the train must be considered, including its physical state 
(e.g. current position, speed) as well as the controller state and timers. Since, 
however, the station computer cannot directly access the environment variables 
but only the commanded speed and acceleration, it must use an approximation 
of those variables. Some of the variables can be obtained by measurement, 
e.g. the current speed and position. Other variables, like the current controller 
state or acceleration, must be deduced from the available input and output of 
the system. Typically for embedded systems, these deduced approximations 
form an internalized model of the environment to be controlled; using a perfect 
model, optimal control can be achieved. In the following, we show a worst case 
computation which uses a simple internalized model of the train. 

To develop this computation, we consider all (re)actions of the train relevant to 
the worst case condition. Figure 7.12 shows an extended worst case stopping 
profile (for a train in propulsion as well as braking mode), starting from the 
generation of a status report and ending with the failsafe stop of a train. It 
consists of three main phases: 

to — Ti: After the status report is generated at time To, the train will continue 
to execute the last valid command. The station computer computes a new 
command using the status report and sends it back to the train. 
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Report Processing Timeout Failsafe Stop Failsafe Stop 



Figure 7.12. Extended Worst Case Stopping Profile 

r i — t -2'. After having received the command - and starting a new execution 
cycle of the train controller in our case - the train then starts to execute 
this command at time point n, issues a new status report, and waits for 
a new command. 

t 2 — t:j: Since no new command arrives, at time point T2 = 2 (i.e., 2 — n 
seconds after n), the train controller will activate the failsafe mode and 
reach a failsafe stop at time point 73. 

The station computer must issue commands - depending on train information 
generated at time To - that - when executed by the train at time n - will lead to 
a failsafe stop at time T3 when no new command is received until time t -2- Thus 
we need an internalized model of the environment: 

1 to calculate an estimate of the variables of the train at time n using the 
information available at time To, 

2 to calculate the effect of the issued command from time ti to T3. 

When constructing the internalized model of a train used by the station com- 
puter, we basically introduce a corresponding variable for every variable used 
in the model of the environment; accordingly, corresponding computation steps 
are introduced. To simplify the computation, e.g. to cut execution time, without 
endangering the safety conditions, we can use a more abstract model by fixing 
a variable of the environment to the value leading to a maximum worst case 
stopping distance with respect to that variable. This is especially applied to 
discretize continuous variables like duration times. Furthermore, we are inter- 
ested in a deterministic computation. Therefore, a similar technique of worst 
case values are used in case of non-deterministic behavior of the environment. 
Thus, possible simplifications are: 
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Fixed-length transitions. To abstract from timers, state changes (e.g. coasting 
to engaging brakes) are discretized to occur only at the e = 0.5 sec cycles. 
In-between transitions arc delayed to the nearest safe step. 

Simplified distance/speed calculations. Instead of considering acceleration 
and jerk rates when calculating distance <5i reached at n, we use a simple 
linear scheme using only the maximum speed encountered during this 
interval (and its monotonicity of velocity): 



5i(v 0 ,vi) = 0.5 x max(v 0 ,vi) (7.2) 



Bounds. To avoid non-deterministic wheel slippage caused by humidity, a fixed 
worst case brake rate mhr = — 1.2 mphps can be used. 

As we will see in Subsection 4.5, these simplifications do not compromise the 
safety condition of Equation 7.1 

Combining the above simplifications with the worst case stopping profile, we 
can define the calculation of a worst case stopping distance as a function wcsd 
with the internalized state of train (s), the last reported speed (v r ) and inter- 
nalized acceleration ( a ), the currently valid command (v c , a c ), and the new 
command to be issued (v' c , a' c ) as its arguments. This distance is obtained by 
calculating the distances 8\, 82, and Tj covered during the intervals defined by 
the time points To, ti, T 2, and T3 as depicted in Figure 7.12; each distance itself 
depends on approximations of the speed (17), accelerations (a/), and states (07) 
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fun TBound(tl , v, a, t2) = if tl.pos < t2.pos 

then tl.pos + Nose + delta(tl . s , tl . vel , tl . acc , tl . vcom,tl . acom) + 
wcsd(tl . s , tl . vel , tl . acc , tl . vcom, tl . acom, v, a) < t2.pos - Tail 
else true 

Table 7.2. Bound Check for Avoiding Collisions 



reach at each time point: 

wcsd(s, v r , a, v c ,a c ,v' c ,a' c ) = <5 2 (si, vi,ai,v',a') + S 3 (s 2 , v 2 ,a 2 ) 

delta(s, v r ,a, v c ,a c ) = 5i(v r ,vi) (7.3) 

with .si = <Ji(s,v r ,a,v c ,a c ), v\ = u\ (s,v r ,a,v c ,a c ), etc. 

Equation 7.2 and Table 7.1 show some of those functions 1 (using constants 
from Tables 1.1 and 1.2). The internalized train states (P, EB1, etc.) correspond 
to train states (Propulsion, EngagingBrakes for one command cycle, etc). 
Based on delta and wcsd, we can now define a boolean function TBound 
checking whether a pair of a speed v and an acceleration a commanded for a 
train tl is respecting the safety bounds to avoid hitting a train t2; Table 7.2 
shows its definition as used for the behavior of the System component (with 
Nose and Tail describing the length from the position of a train to its head and 
its end, resp.). 

Similar calculations GBound, SBound, OBound can be defined for the further 
requirements (avoiding to enter a closed gate, to exceed the civil speed of a track 
segment, or to exceed the overall speed limit of 80 mph). Then an allowable 
speed and acceleration for a train - defined by Bound - is 

Bound(t, v, a, Trains, SegTable, GateTable) -(=>■ 

(V t £ Trains. TBound(t, v, a, t) A V s £ SegTable. SBound(t, v, a, ,s)A 
Vg £ GateTable. GBound(t, v, a, g) A 0Bound(t, v, fl))V 
(v = 0 A a = —2.0) 

To define the data state, the arguments of the functions used to describe the be- 
havior (as already indicated above) combined with the structured requirements 
of the first step concerning data types and local data are used. Thus, for function 
TBound a variable Trains collecting the current states of all trains is used with 
a corresponding CDD for its type: 

data TrainStatus = TStat( 

TId : Ident , TMQTT : Tag, s : TrainState , 

pos : Real , vel : Real , acc : Real , vcom : Real , acom: Real) ; 



1 Each table entry presents the values of the functions (right columns) depending on the values of the argument 
(left columns). Entries with are valid for all values of this argument. 
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(Timer <500)&&elem(t rain, I ssues)&&Bound(train,cvel,cao 
Trains,SegTable,GateTable) 
Cmd!Cmd(Tld(train),TMOTT(train),cvel,cacc) 
lssues=remove(train,lssues);Trains=updateCom(Cmd(Tld(train)r 
TMOTT(t rai n),cvel ,cacc),T rai ns);Ti mer=Ti mer+1 



Timer==100::Cmd!:lssues=Trains;Timer=Timer+l 

[V - 



Start Computing 



[ Timer< 450::Cmd!:Timer=Timer+l 




Figure 7.13. Behavior of the System. 



The local data requirement of Subsection 4.1 leads to the addition of train 
identification numbers or message time tags as well as the introduction of further 
variables like the segment table SegTable. 

To define the control space, similarly to the data space, all requirements asso- 
ciated to state information of the station computer are used (e.g. requirement 
Par. 16). Figure 7.13 shows the STD defining the states of behavior identified 
in the structured requirements: 

Collect: Receiving the reports by the trains, (de)registering trains, and col- 
lecting of gate information. 

Compute: Computing speed and acceleration commands for registered trains. 

Issue: Sending the computed commands to the registered trains. 

During transitions of the first step, status messages arc received and the local 
variables (e.g., GateTable and Trains) are updated. In the second state, com- 
mands arc computed. Note that according to the STD description of transition 
Compute, the controller does not actually compute commands but simple idles; 
however, since in this step we only model the externally visible behavior, this is 
an adequate description of the behavior. In Steps 4.6 and 4.6 we will consider 
more detailed descriptions of the computing process. 

During the state of issuing commands, the controller produces command out- 
put for all registered trains and updates the internalized state of all trains. Be- 
sides changing currently commanded speed and acceleration, updateCom also 
changes the internalized state of the train; e.g. a commanded acceleration below 
0.0 changes C to EB1. 
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By introducing explicit time slots for each round (e.g., 50 msec to issue com- 
mands), we removed some of the nondeterminism left open in the EET-based 
specification. Note however that the described behavior is still not immediately 
executable due to the use of a non-constructive description of the speed and 
acceleration selection when issuing a command. To apply simulation, these 
specifications have to be transformed into an executable version. Besides sim- 
ulation, we can now use the consistency analysis described in Subsection to 
ensure that the STD meets the EET-defined protocol. 

4.4 Step 4: Analyzing the Model 

Before checking whether the introduced model meets the safety requirements, 
we should make sure that the model is a “reasonable” model. A reasonable 
model of the environment should of course model the laws of physics sufficiently 
well. Here simulation or formal proof of properties about the environment 
can be used; however, this requires the knowledge on a domain expert (e.g. a 
mechanical engineer) and therefore is out of the scope of our approach. Beyond 
that, a reasonable model should have a consistent description; here, model-based 
development supports the detection of different forms of inconsistencies in the 
models: 

Conceptual Consistency. As described in Subsection 2.2, these properties ei- 
ther are ensured by construction (like interface consistency), or can be 
checked using the AQuA system of AutoFocus. Examples are: 



Variable definedness. Components use only local or interface informa- 
tion (like local variables or input and output messages). This is 
especially important to ensure that the system cannot directly use 
information about the state of the environment (e.g. actual positions 
of trains) but has to rely on derived information (e.g. positions re- 
ported by the positioning algorithm). 

State Hierarchy. Each initial hierarchical state (like the Braking state 
of Figure 7.8) has at least one initial sub-state. 



Input Enabledness. This property requires that the environment cannot re- 
strict the actions of the system (e.g. by not accepting certain commands 
issued by the system as input). Analogously, the system is not allowed 
to restrict the reactions of the environment. 



Responsiveness of Behavior. This property requires that neither system nor 
environment can be taken to an undefined state. While this is obviously 
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reasonable for the environment 2 , it is an important safety requirement of 
the system. 

In an input/output transition based model (as used in AlltoFoCUS), combin- 
ing input enabledness and responsiveness of behavior result in completeness 
of behavior. For methodical reasons, we treat the model of the environment 
and the model of the system differently when analyzing completeness of their 
behaviors. While we require a explicitly completely defined - but possibly 
non-deterministic - behavior of the environment, we relax this requirement for 
the system. Here we distinguish between 

Input Definedness. There need not be an explicit reaction of the system defined 
for each possible input of the environment. If for some state acceptable 
input is only partially defined (i.e. some precondition/input pattern is not 
accounted for), we allow the system to react arbitrarily (i.e. produce any 
output and change to any arbitrary state), thus resulting in input-enabled 
behavior. 

Output Responsiveness. If an explicit reaction is defined for some input, the 
corresponding output must be defined. Since in AlltoFoCUS the output 
is defined in terms of a function (or relation) over the local data state and 
the data of the input, this function (or relation) must be total. 

To check output responsiveness, criteria for the totality of constructive (sub-) 
functions can be used: 

Totality of Conditionals. If a conditional is used in a functional description, 
the conditional is required to have an else branch (e.g. computation of 
the speed bounds). 

Totality of Look-Up Tables. Only total mapping functions arc used (e.g. for 
the table of track segments, there is an entry for each possible track 
position). 

Like those criteria, many totality criteria can be defined as conceptual consis- 
tency conditions and checked automatically, using, e.g., ODL. In AlltoFoCUS, 
the AQuA framework can be used to perform those checks. For example, to 
check the totality of a segment table t like the track segment table, the condition 

forall seg: {s: Sgmt I is Sgmt(s,t)}-. 

exists next: {n: Sgmt | is Sgmt(n,t)}. next . start=seg. end 



2 Note that the environment may still be in a underspecified state, e.g. with different possible trains speeds 
due to unknown brake rates. 
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can be used. However, when using a non-constructive description of the behav- 
ior of a component, generally those conceptual checks arc not sufficient, but we 
must make sure that this description is satisfiable. In the introduced definition 
of the behavior of the station computer, such non-constructive description is 
used. Since the commanded speed and acceleration arc defined to be selected 
from a set of speeds respecting the worst case bounds, we must make sure that 
this set is not empty. According to the definition of Bound.a commanded speed 
of 0 and a commanded acceleration of —2.0 is always a satisfying speed and 
acceleration. 

While incomplete input definedness is acceptable in requirements analysis and 
early design, undefined behavior generally is a possible source of faulty behavior 
and therefore has to be removed in later steps. To complete a specification, either 
its explicit extension or a canonical completion - as described in Subsection 4.8 
- can be used. 

4.5 Step 5: Establishing the Requirements 

Having introduced a suitable model of the environment and the system, we 
can now use these models to validate or verify that the behavior of the system 
leads to the desired behavior of the environment; especially, to analyze the 
quantitative quality and safety measures to be demonstrated according to the 
requirements. For sake of brevity, we do not treat those applications in detail 
but rather focus on the principles behind them. 

Qualitative Properties. Using the model of the environment, in Subsec- 
tion 4.3 we have formulated a safety requirement ensuring that no train hits a 
leading train. In the following we sketch how the property of Equation 7.1 is 
established. To verify invariant properties about the state space of a system, 
generally induction is applied, consisting of two steps: 

Base Step. In the first step, we show that the system is initially in a safe state. 

Induction Step. In the second step, we show that whenever the system is in a 
safe state, any possible transition will take it to another safe state. 

According to the model of our environment, we require that initially trains arc 
sufficiently spaced and each train is not moving and applies maximum brake 
rate. Trivially, this state is safe in the sense of Equation 7.1. However, the 
property is not sufficiently strong for the second step. Obviously, freedom of 
hitting a train does not sufficiently characterize a safe state of a system: a train 
short of hitting a leading train cannot avoid hitting it if its speed is to high to 
brake within the remaining distance. 

Obviously, while the behaviors of the station and the trains ensure the property 
of Equation 7.1, this property is not sufficiently strong to be proved by induction. 




AlltoFoCUS - Mastering the Complexity 



245 



However, the combined behaviors of system and environment ensure a stronger 
property, since the system computes its commands on basis of a worst case 
distance. Therefore, the needed invariant conditions, as also stated in Par. 57 
is: “A train (is never) (...) physically within the worst case bounds of (...) the 
real - of a leading train.”; or, more formally: 

Vr G T.Vfi ,?2 € Trains. t\.pos T <t 2 -pos T =$■ (7.4) 

ti.pos T -\- Nose + wcsd(ti <T ) < t 2 -pos r — Tail 

Thus, while in Subsection 4.3 we used the principle of the worst case stopping 
distance to let the station computer compute a reasonable command, we now 
use this principle to define a stronger safety invariant. Note that therefore the 
function wcsd used in Equation 7.3 differs from the function wcsd used here 
in Equation 7.4: while the former is defined in terms of internalized variables 
of the system, the latter is defined in terms of variables of the environment. As 
shown in Table 7.3, it depends on the state (cs), time until fail safe mode (c/) 
defined by tag, clock, and Cycle, commanded velocity and acceleration (cv, 
ca), timer of the controller (ct) defined by Timer and Cycle, as well as state 
(ms), timer (ml), speed (v), acceleration (a), and commanded acceleration (me) 
of the train model. Obviously, Equation 7.4 is indeed also a stronger version of 
Equation 7.1, since wcsd(t T ) > 0 for all r G T. 

The worst case function is defined along the lines of Par. 38 to Par. 49. How- 
ever, for the description given there (as well as for wcsd as used by System), 
it was sufficient to define the worst case stopping distance only for time n, 
when execution of the last command starts. Here, in contrast, we need a wcsd 
version defined for every time point between n and t>, to make it applicable for 
induction. Table 7.3 shows the definition for a train in different modes, using 
abbreviations for the different states (for the train controller, e.g. N and F for the 
states Normal and FailSafe, resp.; for the physical train model, EB and P:D 
for the state EngagingBrakes and sub-state JerkDown of state Propulsion, 
resp.) as well as abbreviations from Table 1.2. 

Based on this wcsd function, we can now validate the invariance property of 
Equation 7.4 for an environment controlled by commands of the System compo- 
nent. Since obviously, the validity of the invariant depends on the commands, 
we add the state of the system to the proof to describe the correctness of the ex- 
ecuted commands. As defined in Step 3 in Subsection 4.3, the system state for a 
specific train is the information stored in the corresponding TrainStatus, e.g. 
pos for the last reported position or vcom for its currently commanded speed. 
Since the internalized model used by the system sets the basis for the calculation 
of the commands, as a first proof step we establish that the physical model of the 
train is always bound by the internalized model of the system when a command 
is executed. This includes to establish properties like 

t.pos < f.pos + delta(f.s, f.vel, t. acc, f.vcom, ?. acorn) (7.5) 
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cs 


ct 


cf 


ms 




wcsd(cs, cf, ct, cv, ca,ms, mt, v, a, me) 


N 


> 0 


> ct 


P : C 




v x ct + wcsd(N,cf — ct, 0,cv,ca,P : C, 0,v,a,mc) 


N 


0 


> ct 


P : C 




w«d(N, cf, 0.5, cv, ca, P : C, 0, v, a, me 1 ) 
with adjust_acc(v, cv,ca) = me' 














N 


- 


0 


- 




wcsd( F, 0, 0, 0, 0, ms, 0, v,a, —2) 














F 






P:D 




VXT+^XflxU — 3 x J P X T 6j t 

wcsd{ F, 0, 0, 0, 0, P : C, 0, v' , 0, -2) 

with r = a/Jp and v' = v + ax t — | xJpXr 2 


F 


- 


- 


P : C 




wcsd(F, 0, 0, 0, 0, EB, MC,v, 0, —2) 


F 


- 


- 


EB 




v x mf + wcid(F,0,0,0,0,B:D,0,v,0,— 2) 


F 






B : D 




v x rf 2 x ax t g x Jp x t F 

wcsd(F, 0, 0, 0, 0,B : H, 0 ,v' ,mbr, —2) 

with r = (a — mbr)/JB, v' = v + axr+^ xJpXr 2 


F 


- 


- 


B : H 




— 1/(2 x mbr) x v 2 



Table 7.3. Worst Case Stopping Distances for Different States of a Train 



to hold at t\. Because these properties relate the status reported by a train to 
its current state when executing a new command, the proof is established by 
creating a chain of states, starting at To and ending at t\. 

After linking the models, in the second step we relate the estimated effect of 
a command (i.e., distance wcsd used by System) to the desired effect on the 
environment (i.e., distance wcsd used as invariant). Using the results from the 
previous proof step, we can establish the state property 

wcsd(f.s, f.vel, Dace, f.vcom, ?. acorn) <wcsd(t ) (7.6) 

for the current state of all variables at time n and using an unfolded version of 
wcsd according its definition in Equation 7.3. 

Using these results, in the final step we check whether all transitions of the en- 
vironment are safe concerning the invariant property. Since we have 2 different 
kinds of transitions, we use 2 different techniques: 

Command Processing. This paid ensures the safety invariance when executing 
the Command transitions of Figure 7.7. Since these transitions are the only 
ones controlled by the System, here the station computer calculations 
and therefore the previous results are applied . Using the properties of 
Equation 7.5 and 7.6 (and auxiliary properties like Vr 6 T. Epos r < 
t.pos T ) w e immediately establish 



tl.pos + Nose + wcsdftl) < t2.pos — Tail 
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by means of the property of TBound as stated in 7.2. 

Controlling Train. Since wcscl is defined inductively over the states encoun- 
tered from r i to t 3 , we show that each transition maintains the invariance 
condition by relating the variables changed (especially the distance cov- 
ered) when taking a transition, to the corresponding change concerning 
the wcsd. 

Since our models are not accessible to automatic model checking (especially due 
to their hybrid character), a more general proof support is needed. Therefore, 
as mention in Subsection 4.3, here the STeP prover system is applied using 
both automatic and interactive techniques to establish the proof. To ease the 
understanding of the proof in spite of its complexity, the Verification Diagrams 
of STeP help to structure the first and third proof step. 

Quantitative Properties. When considering the qualitative properties of 
the systems, we arc interested in their total correctness, i.e. the proof whether 
these properties do always hold assuming that no component of either system 
or environment fails to execute the defined behavior (which may - as in the case 
of the network - also include faulty behavior to be compensated by the system). 
However, when considering quantitative properties like MTBH, we arc rather 
interested in the probability that these qualitative properties hold during a certain 
period of time. 

In the following we will use a simple exponential distribution for the probability 
density function (see, e.g. [MI087]). This distribution leads to a constant 
hazards rate and is therefore especially suitable for stable software ignoring 
“burn in” and “wear out” effects. In this model, the probability density/(f) of 
a component to fail at some time t is defined by 

f(t) = Aexp(— At) (7.7) 

for some A > 0. Accordingly, the reliability function R(t) describing the fact 
that a system will function properly up to some time t, the hazard rate z(t) 
stating the probability that a system will break down at time t, and finally the 
average life time (or MTTH, mean time to hazard) E[T] for this distribution arc 
defined by 



m 


= exp(— A t) 


(7.8) 


z(t) 


= A 


(7.9) 


E[T\ 


= A ’ 1 


(7.10) 



In Subsection 4.5 we made (qualitative) assumptions about the environment 
(like the behavior of the train) or parts of the system (like the accuracy of the 
position algorithm). By assuming total correctness of those components, total 
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correctness of the complete system can be deduced. To deduce quantitative 
properties of the system like MTTH, we will relax the assumption of total cor- 
rectness of those components: we no longer assume that these components 
always function properly; rather we assume that the correctness of their func- 
tionality is subject to a probability density as described above. Therefore, we 
schematically extend our total correctness proof to a quantitative analysis of 
the system by adding a probability distribution to those component properties 
used to establish total correctness. Using those distributions we then calculate 
the average life time of the complete system, i.e. the average time the system 
will provide those properties verified under total correctness assumption. 

In the first step of the reliability analysis, we investigate the list of explicit 
assumptions which were needed to establish the proof of correctness in the 
previous subsections. For each of those assumptions we fix a probability dis- 
tribution that this assumption is met by the real system; for completely reliable 
software or hardware components a constant distribution of 100% reliability 
is used. In the following, we relax to the properties assumed in the above 
subsections: 

Assumption about a discrete part. The probability that the position estima- 
tion algorithm produces an estimate out of the bounds is less then 10~ 14 
per execution. 

Assumption about an analogue part. The constant failure rate of the brakes 
(i.e. probability that the brake rate is below the bounds) is less then Hr 1 1 
failures per hour of operation. 

Furthermore, we could also add properties of the implementation platform, e.g. 
the reliability of the Vital Station Computer introduced in Step 6 in Subsection 
4.6, which however in the case study is supposed to meet MTBH requirements. 
Finally, we use the structure of the system and the environment as defined by 
the corresponding SSDs constructed in Step 2 in Subsection 4.2 to analyze 
the reliability of the system. To simplify matters, we only analyze a system 
consisting of 1 station computer and 10 trains. Based on this structure and the 
total correctness proof, we can construct a reduced Failure Model and Effect 
Analysis ([Law83]) of the system, using only one class of fault (i.e. component 
is not functioning properly). Since analogue and discrete parts of a system 
usually have different time frames, we have to convert them to a common time 
basis. Concerning the critical components positioning algorithm and braking 
system, we use hours of operations as time basis and therefore have to convert 
the failure rate of the positioning algorithm from the discrete time base r of 
the scheduled executions to the time base t of hours of operation. According to 
[MI087], an average utilization p c is applied for conversion of a component c: 

K, = Pc x \ r 



(7.11) 
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For the positioning algorithm, we have ten applications per cycle (one for each 
train) with a cycle length of 0.5 seconds, again as defined in Step 2. Therefore, 
we obtain a utilization factor of 

10 x (0.5) -1 x 60 x 60 = 7.2 x 10 4 

Once all components arc converted to a common time frame (for analogue 
components often a utilization factor p = 1 can be used), we analyze the 
message flow as defined by the SSDs of system and environment, and arrive 
at the following situation: during each period, the failure of one component 
can lead to a hazardous situation, requiring the correctness of all components. 
Accordingly, this And Configuration [MI087] has a system reliability defined 
by 

R=llR c (7.12) 

esc 

for a set C of critical components (all other components arc assumed to be 
perfectly reliable). By applying Equation 7.12 to 7.8, we obtain system-wide 
versions of Equations 7.9 and 7.10. Using exponential distributions A c for all 
critical components c £ C as described in Equation 7.7 based on a common 
time frame by means of Equation 7.1 1, we obtain a combined hazard rate z(t) 
and a combined average life time E\T] of 



z(0 


= 


(7.13) 




esc 




E[T] 


= C^p c y. KX 1 


(7.14) 



esc 



Since in Equation 7. 12 C subsumes all critical components, we have to consider 
of course all instances of components: according to the system structure, we 
have only 1 instance of the positioning algorithm but 10 instances of the braking 
system, one for each train. Applying Equation 7.13 to the above assumption 
we obtain a combined hazard rate of 



z(t) = 10 x 1 x 10“ n + 7.2 x 10 4 x 10~ 14 = 8.2 x 10~ 10 

of hazards per hours of operations, and therefore according to Equation 7.14 a 
MTTH of 

E[T] = 0.122 *10 10 (7.15) 

measured in hours of operation. 



4.6 Step 6: Refining the Structure of the System 

During Step 1 in Subsection 4.1, a component requirement was identified for 
component System stating that “the station computer itself is divided into 2 
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Figure 7.14. Refined Structure of AATC. 

systems" (Par. 57): the Vital and the Non- Vital Station Computer, resp (VSC, 
NVSC). To cover this requirement, the structure of System as introduced in 
the second step in Subsection 4.2, is refined as shown in Figure 7.14: 

Vital Station Computer: delegating command calculation to the NVSC, and 
checking whether suggested commands respect the worst-case bounds. 

Non- Vital Station Computer: computing improved commands and forward- 
ing them to the VSC for validation. 

Since the behavior of the Non- Vital Station Computer will be detailed in the 
following steps, we use an extreme form of underspecification for is behavior: 
no restriction is imposed on the calculated commands. The behavior of the 
VSC is sufficient to ensure that the behavior of the refined System is meeting 
the description of the abstract System introduced in Subsection 4.3. As shown 
in Figure 7.15, the behavior of the VSC exhibits the same states and similar 
transitions as the behavior of System. Besides the delegation of commands 
to the NVSC, the major change is the substitution of the Issue Command 
transition of Figure 7.13 by 2 transitions: 

Pass command: passing on a command suggested by the NVSC if it meets 
the safety bounds 

Issue command: issuing a break command (with speed 0 and acceleration 
—2.0), if the safety bounds arc exceeded 

To show that the refined system of VSC and NVSC implements the original 
System, therefore it basically suffices to show that those 2 transitions imple- 
ment the original one, which corresponds to showing the the break command 
meets the safety bounds. Assuming arbitrary behavior of the NVSC, we can 
even establish an equivalence between both systems. To formally verify this 
implementation relation, the different proof tools connected to AlltoF OCUS can 
be used. 

By this form of partitioning we have established a further requirement identified 
in the first step (Par. 20) which states that for each train during each round of 
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(Timer<500)&&elem(t rain, lssues)&&(Bound(t rain, TVCom(t rain), 
TACom(train),Trains,SegTable,GateTable)==false) 
OutCmd!Cmd(Tld(train),TMOTT(train),0,-2.0) 
Timer=Timer+l;lssues=remove(train,lssues);Trains=updateCom( 
Cmd(Tld(train),TMOTT(train),0,- 2.0), Trains) 




Figure 7. 15. Behavior of Vital Station Computer 




Figure 7.16. Abstract Behavior of the NVSC 



computation the “VSC cannot do more than essentially one computation of a 
bounding speed and acceleration.” 

4.7 Step 7: Reducing Underspecification 

After refining the structure of the System in the previous step, we now define 
a suitable behavior of Non-vital Station Computer. Figure 7.16 shows a 
simple behavior to start from, just sticking to a basic interaction protocol with 
Vital Station Computer. Since we start out with a broadly undefined be- 
havior, this step consists of of refining the behavior of the system by eliminating 
some underspecification. With reactive systems, we have two different forms 
of behavior: 
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Computation. Like procedural programs, reactive systems perform compu- 
tations, calculating the values of variables depending on the values of 
others. These computations arc performed in one (uninterrupted) step 
without further interaction with the environment. In AutoFocus, com- 
putations, e.g. occur in form of the functions used in the pre- and post- 
conditions of the transitions. 3 

Interaction. In contrast to procedural programs, reactive systems perform their 
computations repeatedly. Each computation step is influenced by the 
interaction between the system and the environment; here, the timing and 
duration of each computation in relation to these interactions is important. 
In AutoFocus, this corresponds to the repeated execution of transitions. 

Correspondingly, there arc 2 forms of refinement: 

Computational refinement. If a computation is underspecified - like the rela- 
tion Compute in Figure 7.16 - allowing different results, a more refined 
implementation can restrict this non-deterministic computation. 

Interaction Refinement. If an interaction is underspecified - like by means of 
the non-deterministic choice between the Compute and Issue transitions 
in Figure 7.16 - allowing different possible sequences of interaction, a 
mode refined behavior can restrict this non-deterministic choice. 

To demonstrate both forms of refinement, we define a simple command opti- 
mization strategy for the NVSC to avoid large changes in acceleration during 
propulsion mode, as stated in Requirement Par. 50. 

To refine the computation, we break it up in 2 steps: first we compute the 
maximum commanded speed and acceleration respecting the check performed 
by the VSC; then the speed selection is optimized. 

By means of a functional valiant computeMax of Bound in the first step, 
we obtain a maximum safe speed v max and acceleration a max . Since any 
speed/acceleration pair below these is a suitable command, too, the result of the 
first step is the region from (0, —2.0) to (v max , ci max ). In the simple optimization 
step, we now reduce this non-determinism by applying function smooth_acc, 
ensuring a maximum jerk of 0.5 mphps per step: 

smooth_acc(v, a , v c , a c ) = max(n + 0.5, adjust_acc(v, v c , a c )) 

with adjust_acc as introduced in Subsection 4.2. Since the second step 
returns a (non-empty) sub-region of the first, their combined application is a 
computational refinement. 



3 For complex computations, AutoFocus uses a description technique not introduced here to describe the 
computational data flow. 
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Figure 7.17. Refined Behavior of Compute 



By splitting the computation into different parts, these parts can be assigned 
to consecutive steps in the behavior of the NVSC. Using STDs, e.g. we as- 
sign 3 sub-states to the Compute state, and distribute the computations and 
interactions on their connecting transitions, as shown in 7.17. The new modi- 
fied behavior is obtained by replacing the Compute state by the sub-automaton 
containing the new states and corresponding transitions. By means of interface 
consistency, AlltoFoCUS ensures that this replacement is well-defined. Similar 
to the component/sub-component refinement step discussed in Subsection 4.6, 
we can now verify whether the modified behavior of NCSV refines its original 
behavior, using the proof tools linked to AlltoFoCUS. 

The current description of the calculated commands still leaves room for further 
optimization since we still did have a range of possible commands to choose 
from. For the final solution, we arc - of course - interested in a constructive 
description of the command selection. Accordingly, e.g. the maximum of 
that range can be chosen as a simple implementation. This corresponds to the 
design decision that, once all other objectives concerning speed an acceleration 
arc met, a train should travel as fast as possible. 

4.8 Step 8: Increasing Robustness 

Since the operations of the station computer, and especially the Vital Station 
Computer, arc safety critical, we want to make sure that its transactions arc 
complete, i.e. we have a completely defined input and output behavior. During 
Step 6, we arrived at a constructive description of the behavior of the com- 
ponent; therefore we can ensure output responsiveness using the techniques 
introduced in Step 4 in Subsection 4.4. To ensure a completely defined input, 
we have to make sure that in each (control and data) state of Vital Station 
Computer for each message received at its channels there is a corresponding 
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transition. AutoFocus currently offers input definedness analysis based on 
symbolic model checking. 

The Vital Station Computer exhibits some undefined behavior caused by 
the status reports to be handled by the station computer. Checking for complete- 
ness reveals, e.g. the missing input pattern for the St channel in the Collect 
and Issue states. According to our assumption - as stated in Step 3 and in- 
corporated in the model of the environment - status reports are sent out only 
during the protocol slot reserved for status messages. Since faulty behavior 
(clock drift of a train, jitter in the network, etc.) however may compromise 
this assumptions, we are interested in complete input definedness capable of 
detecting such situations. By adding corresponding transitions, we can add 
appropriate reactions (e.g. issuing a warning to the operator desk). 

The behavior of the Non-vital Station Computer also exhibits uncom- 
pleted input definedness; e.g. when calculating commands, again no reaction 
is defined in case a new report is received. In such a case, both simulation 
and code generation perform a standard completion : non-definedness is re- 
solved by ignoring the received message. Since due to the behavior of Vital 
Station Computer such a situation cannot arise, operational completion as 
default treatment may be seen as sufficient. However this reaction of the VSC 
might indicate a failure of its computation; therefore a more complex reac- 
tion to these unexpected situations (e.g. a shut-down of the system) might be 
reasonable to increase the robustness of the overall system. 

Once having established a complete behavior, we eliminate another source of 
possible defects by making sure that the transitions are deterministic. By com- 
paring the enabling conditions of all pairs of transitions, AutoFocus checks 
whether 2 transitions arc enabled by the same (control and data) state and mes- 
sages received. While this does not necessarily result in non-deterministic or 
even faulty behavior, in embedded systems this situation generally is unwanted. 
However, since both components already arc defined deterministically, no fur- 
ther steps arc required here to end up with a robust implementation. 

5. Results raised by this technique 

Model-based development is all about adding the structuring and preciseness 
of formal approaches to the development process while being driven by the 
models of the application domain instead of mathematical formalisms. Thus it 
helps reducing the complexity of the development process by clearly focusing 
on specific issues and offering suitable, generally CASE-supported techniques 
tailored for each step of the development: 

Step 1: By linking informal requirements and the model of system and envi- 
ronment, we can mechanically check whether all informal requirements 
arc covered, trace back which requirements are related to design deci- 
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sions, and analyze the impact of changing the informal requirements on 
the model; but most importantly, it helps to structure the requirements, 
get a better understanding, and identify open issues in the requirements. 

Step 2: By modelling the environment and its interface to the system, we 
avoid implicit assumptions about the environment and get a precise un- 
derstanding of how the system can influence the environment, how the 
environment reacts to such influences, and what data can be obtained of 
the environment. Especially important, we precisely state what proper- 
ties of the environment we take for granted and which possibly faulty 
behavior we must tolerate to establish the required safety behavior of the 
system. 

Step 3: By defining the abstract, possibly incomplete and non-deterministic 
behavior of the system, we describe a high-level initial design without 
already incorporating implementation details complicating the design or 
limiting further decision. Furthermore, we establish the basis for further 
analysis and development steps. 

Step 4: By analyzing the models of system and environment for their validity, 
we ensure their usefulness for the following steps; using simulation or 
conceptual consistency checks, we identify open issues like unrealistic 
behavior of the environment, as well as missing input definedness or 
output responsiveness. 

Step 5: By using even stronger techniques we establish whether the defined 
behavior of the system ensures the expected behavior of the environ- 
ment. Using formal verification, we show that the system guarantees the 
safety requirements of the environment assuming optimal circumstances; 
furthermore, using failure analysis, we show that also meantime require- 
ments arc met using quantitative assumptions about the environment. 

Step 6: By applying structural refinement, we add further design decisions 
concerning the architecture of a system by breaking it up into interacting 
sub-components. By adding behavior to each sub-component, we can 
make sure that the refined system implements the abstract one. 

Step 7: By restricting non-deterministic or undefined behavior, we add further 
design decisions concerning underspecified behavior of the introduced 
components, resulting in a more optimized reaction of the system while 
maintaining the overall functionality. 

Step 8: By checking the components of the system for possible undefined 
behavior we identify remaining open behavior to be resolved in the final 
implementation. By adding standard reactions for open behavior, we 
improve to the robustness of the system against unexpected behavior. 
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6. Conclusion 

In this chapter we introduced the AutoFocus approach to model-based devel- 
opment of reactive systems. In the demonstration, we focused on the application 
of the approach to the BART case study rather than on the underlying theo- 
retical foundation, more general issues of model-based development, or the 
CASE tool behind the AutoFocus approach. The reader is referred to [BS01], 
[SPHP02], and [BLSSOO] for further details on those subjects. In a nutshell, a 
model-based approach as presented here offers several benefits: 

Improved product. By moving away from an implementation biased view of 
a system, the developer can focus on the important issues of the product 
under development. This results in: 

■ thinking in terms of the domain-specific conceptual model (state, 
component, interaction, etc.) instead of the coding level (objects, 
method calls, etc.) 

■ narrowing the gap between informal specification and formal spec- 
ification (since, e.g. notions like mode, event, or communication, 
appeal - in the informal specifications of the application domain as 
well as in the conceptual model.) 

■ limiting the possibility of making mistakes while building mod- 
els and refining them by ensuring invariant consistency conditions 
(e.g. separation of environment, interface, and system) and variant 
consistency conditions (e.g. absence of undefined behavior.) 

Improved process. Using a better structured product model helps to identify 
more defects earlier. Additionally, higher efficiency can be obtained by 
more CASE-supported process steps: 

■ mechanizing conceptual consistency conditions, either guaranteed 
by construction (e.g., interface correctness) or checked automati- 
cally on demand (e.g., completeness of defined behavior) 

■ supporting semantical consistency conditions, either automatically 
(e.g., checking whether an EET can be performed by system), or 
interactively (e.g., by ensuring safety condition of a system) 

■ enabling transformations of specification (e.g. inserting standard 
behavior for undefined situations), interactively carried out by the 
CASE tool. 

The limit of model-based support is defined by the sophistication of the un- 
derlying conceptual and semantical model: by adding more domain-specific 
aspects to it, even more advanced techniques can be offered like supporting 
reliability analysis for the BART system or calculating safe task schedules for 
the Vital Station Computer. 
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Abstract This last chapter does consider two main points : 

1 ) Are formal methods an appropriate answer to model safety critical distributed 
systems? 

2 ) What should be a right development process for the development of such 
critical systems? 

As editors, we are of course convinced that formal methods are the only way to 
design and develop safety critical distributed systems. We not suggest any new 
notations, nor new processes. 

We claim that, instead of reinventing the wheel, it is possible to take advantage of 
current notations, by mixing them carefully, that means providing right notations 
for specifying right properties. In other words we recommend to start from semi 
formal notations that must be used in coordination with some dedicated ones all 
over the development phases. 

Moreover we believe that the chosen process must fit the capabilities of the 
development team. This second consideration is certainly the most important by 
product of the Dagsthul seminar. 



1. Are Formal Methods an appropriate answer to the 
Design of Distributed Systems? 

A careful reader might ask the question whether using so many formal notations 
is really a right way to design safety critical distributed systems. So far, a lot of 
distributed system have been developed without using such formal notations. 
They do exist, and are used by many people! It is true they are not really secure, 
nor safe. When they crash, their failure may unfortunately dangerously impact 
their environment. 

Moreover, (most of) the solutions presented in previous chapters present several 
drawbacks. 
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■ They are partial regarding "traditional" software development. 

As written in the introduction they allow to consider a rather small subset 
of a real development. In Chapter 2 the only formal specified part is the 
the control algorithm. In Chapter 3 the formal paid is relative to the static 
view of the BART system. In Chapter 5 again the specified part is relative 
to the control algorithm, complemented by generation of tests that allow 
to check the formal models. And so on! 

■ They are difficult. 

As the reader may have noticed, many different formal notations have 
been used. Some are proprietary, some have been adapted. All of them 
suppose a deep background in Software Mathematics 1 . In all chapters, 
the involved formal notations are quite specialized (i.e. dedicated). Con- 
sequently, it seems impossible to ask any Software Engineer to dominate 
all the formal notations presented in this book. 

■ They do not help validating models. 

Indeed, as it is clear from Chapter 3, any validation step requires a sound 
and stable basis. Unfortunately an SRD (System Requirements Docu- 
ment), which will stay informal even in the long term, cannot be such a 
required basis. Validation for upper development phases is based on 
"weak" techniques. As explained in Chapter 3, validation for upper 
phases is always possible thanks to "cross reading" and "inspections". 
Unfortunately these techniques arc semantically rather "weak". 

On another hand, formal notations offer some interesting advantages, which arc 
the counterparts of the drawbacks enumerated above. 

■ They are partial from an expressive point of view. 

As written above, the used notations arc dedicated either to static aspects, 
or to dynamic ones. Some may argue that this is more an advantage than 
a drawback! The editors arc really in favor of the second interpretation 
because a separation of concerns leads to much more pertinent develop- 
ments. 

■ They are precise from a specification point of view. 

Undoubtedly specifying part of a system with formal notations, whatever 
they are, is as difficult as coding with a programming language! In 



1 The editors believe that the traditional mathematics (those taught in University) have been diverted a lot 
from their original meaning. Indeed they have been extended to support new contents. For instance some Z 
inference rules are quite new ! Concurrently a new way of using them has been suggested. The way proofs 
are conducted with PVS and other theorem pro vers is not the classical way we have been taught for proving! 
This is why we prefer to use the term "software mathematics". 
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all cases, the specifier/developer must carefully managed semantics of 
both the system, and the used notation! The resulting specification is a 
document, which is, hopefully, more precise, abstract, and readable. 

Formal methods have the following capabilities: 

- Precision : a formal language is given, by definition, a semantics. 
For any sentence, one and only one meaning is available, as far as 
the syntax is correct. No other interpretation is possible. 

- Abstraction : a formal specification should be as abstract as pos- 
sible. This has as main consequence that programming languages 
cannot be used for specification. A rather much more interesting 
consequence of abstraction is its ability to help decreasing the com- 
plexity of a system. 

- Readability : finally it is clear that formal notations arc much 
more readable than programming languages. When developpers 
exchange documents, they need to share one only semantics. This 
will be the case with formal notations, as it is for semi formal no- 
tations such as UML. 

■ They meet important requirements. 

This is again a direct consequence of using formal notations. Both func- 
tional and non functional properties (i.e. constraints) can be expressed 
with formal notations. As discussed above, depending on the input of the 
considered development phase, the specification can be verified 2 . 

The above pro- and cons- arguments have been discussed many times in Com- 
puter Science. Solutions proposed in this book arc new contribution. Never- 
theless, all presented techniques have two common points: 1 ) the use of a semi 
formal notation (UML) as a starting point for all the developments, and 2) the 
scalability of formal notations! 

The reader is easily convinced that UML has been extensively used by the 
presented notations. Even Chapter 7 that is a methodological chapter does 
reuse UML! 

As far as the BART system is large, it is clear that all the presented notations 
treat the problem at the right scale. In other words, because the problem has 
been cut, thanks to UML and its underlying process, into smaller pieces, the 
scalability is no more a problem. 



2 The editors do make a difference between "validation" that is a process based on simulation and testing 
and "verification", that requires mathematically based proof or exhaustive exploration (model checking) 
techniques 
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2. A process for the Design of Safety Critical Distributed 
Systems 

Having demonstrated that dedicated formal notations arc the right way to design 
(parts of) safety critical distributed systems, two more questions do remain: 

1 Which arc the well suited notations for which design/development phases? 

2 What development process could be suggested? 

No specific answer can be given to these questions. Indeed as the presented 
solutions exhibit, no precise development process is followed, except in Chap- 
ter 7. 

However, two types of approaches should be considered. 

The first one is a long term approach that suggest a brand new development 
process, much more centered on formal notations. This to be invented process 
is far from being elaborated. Many researches are currently investigating it 
and this work will be operational sooner or later. However, such an approach 
remain too expensive (it still requires highly skilled specialists) to be used in 
"classical" industrial projects. 

The second one is a short term approach that suggest a design/development 
process. From a practical point of view it must be remembered that development 
teams do have an important background that has to be preserved and enriched 
as much as possible. Regarding current system development techniques, and 
the explicitely (or implicitely) involved processes, it is necessary to extend 
it in a way that each needed formal notation may fit in its right place in the 
design/development process. 

As an example the editors may suggest to adopt a "traditional V model", and 
then to identify step by step, which formal notation can be used. In other 
words, formal notations are used as a complement. The choice of each formal 
notation is based on both the expertise of developers, and on the needs in the 
corresponding development step. This is clearly revealed in this book. 

Another important point also has to be considered: choosing a formal nota- 
tion should directly depend on the usability of a least one tool. As shown by 
chapters 5 and 6, the involved tools allow to better asses the (dedicated) formal 
specification. 

As a final word, the editors believe that, as demonstrated during the Dagsthul 
seminal - , formal methods can be useful for the design and the specification 
of critical system. This use however requires a design/development process 
adapted to semi formal notations. To each semi formal notation, a more formal 
one should be associated as well. The later one should be supported by tools. 
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This rather simple design/development process is a two-dimension one. A ver- 
tical dimension that follows the down line of a "V-cycle model". An horizontal 
one that allows to transform a semi formal model into a formal one that is as- 
sessed through an appropriate support tool. This two-dimension process may 
be regarded as an extension of any classical development process ; formal no- 
tations arc then additional (and more precise) ways to help design/development 
of highly critical systems. 




